Teknik Rehber · Depolama ve Yedekleme

ZFS Replikasyonunda Bant Genişliği ve Gecikme Planlama

Teknik gözden geçirme: 2026-10-06

Mimari ve çalışma modeli

ZFS incremental send ortak snapshot sonrasındaki değişiklikleri aktarır. Aktarım büyüklüğü görünen dosya farkıyla aynı olmayabilir; blok değişimi, metadata ve sıkıştırma kipi sonucu etkiler. Replikasyon başarılı olsa da hedefte uygulanıp erişilebilir hale gelmeyen veri RPO kabulüne dahil edilmez.

İlk tam kopya, düzenli değişim ve kesinti sonrası backlog için ayrı kapasite hesaplayın. Replikasyon linki sürekli gelen değişim hızından yavaşsa kuyruk hiçbir zaman kapanmaz. TrueNAS arayüzündeki görev ölçümleri ile temel ZFS transfer ölçümleri aynı veri penceresini temsil etmelidir.

Sıkıştırılmış veya raw encrypted send seçenekleri hedef özellikleri ve anahtar yönetimiyle uyumlu olmalıdır. Hedef snapshot silme yetkisini kaynak kimliğinden ayırın; replikasyon tek başına bağımsız veya immutable yedek değildir.

1Ortak snapshot
2Değişen blok akışı
3Link ve backlog
4Hedef uygulama ve doğrulama

İlk kopyayı ayrı hesaplayın.

Tasarım parametreleri

Etkin hız: Link hızını değil uygulamanın ölçülen payload hızını kullanın; protokol ve diğer trafik payını düşürün.
Backlog: Kesinti süresindeki değişimi ve günlük normal değişim hızını beraber hesaplayın.
Snapshot bağı: Kaynak ve hedef ortak snapshot silinirse incremental zinciri bozulabilir; saklama politikalarını eşleştirin.

Hesap ve uygulama örneği

Günde 300 GB değişim, ortalamada 3,47 MB/s üretir. Etkin link 10 MB/s ise bir günlük 300 GB backlog teorik olarak 300.000/(10−3,47) ≈ 45.942 saniyede, yaklaşık 12,8 saatte kapanır. Bu ondalık hesap metadata ve yoğun saatleri içermez; pilot ölçümle pay ekleyin.

Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.

zfs send -nP -i tank/data@base tank/data@next
zfs list -t snapshot -o name,used,creation
# Dry-run output estimates a particular stream; actual network throughput still needs measurement.

Hata teşhisi

Belirti	Olası neden / ayrım	Doğrulama
Lag sürekli büyüyor	Etkin aktarım değişim hızından düşük.	Aynı pencerede üretilen ve aktarılan baytları karşılaştırın.
Incremental başlayamıyor	Ortak snapshot eksik.	İki taraftaki snapshot GUID ve saklama kaydını inceleyin.

Kabul ve doğrulama kontrolleri

İlk kopyayı ayrı hesaplayın.
Günlük değişimi ölçün.
Kesinti sonrası backlog süresini test edin.
Ortak snapshot’ı koruyun.
Hedef verisini geri okuyun.
Silme yetkisini ayırın.

İlgili kavramlar

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.

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.

RPO ve gerçek veri kaybı penceresi

RPO, olay sonrasında kabul edilebilecek veri kaybı süresidir. Yedek zamanlaması tek başına RPO kanıtı değildir; işin başarısız olması veya kopyanın karşı merkeze geç ulaşması pencereyi büyütebilir. Olay anı ile kullanılabilir son tutarlı kurtarma noktasının zamanını karşılaştırın. Örneğin olay 14.00'te, doğrulanmış kopya 13.20'deyse o testteki veri kaybı penceresi 40 dakikadır. Hedefi uygulama bazında belirleyin: dosya arşivi ile sürekli sipariş alan veritabanının gereksinimleri aynı olmayabilir.

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.

Şifreleme ve anahtarın yaşam döngüsü

Şifreleme, verinin anahtar olmadan okunmasını zorlaştırır; erişim kontrolü, silinme koruması ve yedekleme farklı ihtiyaçları karşılar. Taşınan veri ile disk üzerindeki veri için hangi katmanın şifreleme sağladığını belirtin. Anahtarların oluşturulması, korunması, döndürülmesi ve acil geri kazanımı tasarımın parçasıdır. Yedeği kurtarmak için gereken anahtar yalnız felaket sırasında kaybedilecek sunucuda bulunmamalıdır. Test ortamında ayrı bir yöneticiyle veriyi açma ve anahtar erişimini geri kazanma adımlarını uygulayın; gerçek anahtarları dokümana veya destek mesajına koymayın.

Saklama politikası ve kapasite

Retention, hangi kurtarma noktalarının ne kadar süre tutulacağını tanımlar. Günlük, haftalık ve aylık noktalar aynı veri değişim oranını temsil etmez; tam kopya üretme şekli ve zincir bağımlılığı fiziksel kapasiteyi değiştirir. Saklama kararı, iş gereksinimi ve geçerli yükümlülükler ile teknik kapasitenin birlikte değerlendirilmesini gerektirir. Daha uzun saklama, otomatik olarak daha iyi kurtarma anlamına gelmez: doğru noktanın bulunması ve okunabilmesi gerekir. Politika değiştirildiğinde mevcut noktaların hemen silinip silinmediğini ürün davranışı üzerinden sınayı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.

Bilgi Merkezi