Veri Yolu, Medya ve Koruma Geometrisi

Ön koşul: block, file ve object erişim sözleşmesini; IOPS, transfer hızı, latency ve kapasite katmanlarını ayırabilmelisin. Bu dersin sonunda bir I/O isteğini uygulamadan kalıcı medyaya ve geri dönüşüne kadar katman katman izleyebilecek; front-end ile backend metriklerini karıştırmadan kuyruk, cache ve protokol etkisini sorgulayabilecek; HDD, SSD ve NVMe’yi yalnız “yavaş/hızlı” etiketiyle seçmeyecek; mirror, parity ve erasure coding geometrisini kapasite, performans, hata alanı ve rebuild riskiyle değerlendirebileceksin. Yaklaşık 29 dakika anlatı ve örnek, 18 dakika Arven uygulaması, 10 dakika bilgi kontrolleridir. Ayrıntılı SAN zoning/multipath, snapshot/replication ve ürün sizing’i sonraki derslerin kapsamındadır.

Uygulama bir write çağrısı yaptığında veri doğrudan diske ışınlanmaz. İstek uygulama ve runtime’dan dosya sistemi veya volume manager’a, işletim sistemi block katmanına, sanallaştırma katmanına, multipath ve aygıt sürücüsüne, HBA/NIC ile taşıma protokolüne, switch veya fabric’e, storage front-end portuna, controller işlem ve cache katmanına, backend bağlantı ve koruma grubuna, en sonunda medyaya ilerleyebilir. Okuma yanıtı aynı zincirin tersinde döner; fakat cache hit, read-ahead, write coalescing veya tiering bazı adımları değiştirebilir. Bu haritanın amacı her teknoloji adını toplamak değildir. Her sınırda şu beş soruyu sor: istek hangi kimlikle ve boyutla görünür, sıraya nerede girer, başarı yanıtı hangi koşulda verilir, hata veya timeout nerede yeniden denenir, hangi metrik bu katmanı ölçer? Bir uygulama 20 ms görürken array 2 ms service time gösterebilir; kalan süre host queue, fabric, cache flush, contention veya başka bir üst katmanda olabilir. İki değer çelişmek zorunda değildir, farklı kapsamları ölçer. Front-end ve backend I/O da aynı değildir. Hostun tek mantıksal write’ı cache, parity, metadata, journal, replication veya garbage collection nedeniyle backend’de birden fazla iş üretebilir. Tersine cache bir süre backend trafiğini erteleyebilir ya da birçok küçük isteği birleştirebilir. Bu nedenle host IOPS ile drive IOPS’ı doğrudan kapasite gibi toplama; ölçüm noktası, zaman ve dönüşüm mekanizmasını kaydet.

Medya seçimi yalnız nominal hız veya fiyat/TB karşılaştırması değildir. Döner medyada kafa hareketi ve rotational gecikme random erişimi sequential akıştan belirgin biçimde ayırır. Solid-state medya mekanik hareket içermez ve paralel erişime daha uygundur; yine controller, NAND türü, firmware, over-provisioning, garbage collection, wear, sıcaklık ve doluluk davranışı sonucu etkiler. NVMe bir medya adı değil, host yazılımının non-volatile memory ile iletişimini tanımlayan komut ve taşıma ailesidir. Aynı NAND farklı arayüz ve mimarilerde kullanılabilir; “NVMe var” tek başına uçtan uca hizmet hedefini kanıtlamaz. Linux blk-mq, modern cihaz paralelliğinden yararlanmak için CPU’ya yakın software staging queue’ları ile hardware dispatch queue’larını ayırır. İstek birleştirme, scheduler, driver kaynakları ve hardware queue sayısı gözlenen davranışı etkileyebilir. NVM Express NVMe over PCIe spesifikasyonu host ile SSD arasındaki PCIe taşımasını tanımlar; paylaşımlı array veya fabric erişimi farklı transport ve ek katmanlar getirir. Cihazın teorik queue kapasitesini görmek uygulamanın yeterli paralellik ürettiğini veya CPU/NUMA yolunun doğru olduğunu göstermez. Medya sınıfı veri yerleşimiyle birlikte seçilir. Küçük random write, büyük sequential ingest, yoğun metadata, read-heavy analitik ve uzun süreli arşiv farklı medya ve cache baskısı üretir. Tiering kullanılıyorsa sıcak verinin gerçekten hangi oranda hangi süreyle hızlı katmanda kaldığı; promotion/demotion gecikmesi; cache veya tier miss halinde kabul hedefinin korunup korunmadığı ölçülür. En hızlı katmana bütün veriyi yerleştirmek bazı hizmetlerde gereksiz maliyet, en ucuz katmana yerleştirmek ise öngörülemez tail latency doğurabilir.

Cache latency ve burst emilimini iyileştirebilir; aynı zamanda ölçüm ve veri güvenliği sınırını değiştirir. Read cache tekrar erişilen veriyi medyaya gitmeden döndürebilir. Write-through cache yazının alt katmanda güvenle tamamlanmasını bekler; write-back tasarımında sistem daha erken başarı döndürebilir ve kirli veriyi sonra destage eder. Böyle bir hızlandırma için cache’in güç kaybı ve controller arızasında korunması, mirror veya persistent mekanizması, destage kapasitesi ve failover davranışı doğrulanır. Benchmark cache’in içini ölçüyorsa sürdürülebilir medya performansını olduğundan yüksek gösterebilir. SNIA solid-state test yaklaşımı preconditioning, steady state, workload parametreleri ve cache raporlamasını bu nedenle önemser. Test, cache dolmadan bitmiş kısa burst mü; sistem steady state’e ulaşmış mı; veri seti cache’ten büyük mü; compressible pattern gerçek veriye benziyor mu; drive doluluk ve background work hangi durumda? Bunlar yazılmadan tepe IOPS tasarım kapasitesi değildir. Durability uygulama sözleşmesidir. İşletim sistemi veya storage “write complete” dediğinde veri hangi arıza senaryolarına karşı kalıcıdır? Application journal, filesystem flush/barrier, hypervisor, controller cache ve media arasındaki zincirin her biri doğru davranmalıdır. Bir katmanın battery-backed veya persistent olması üst katmanın flush istemediği, multipath retry’nin duplicate write üretmediği ya da bütün controller çiftinin ortak güç alanından bağımsız olduğu anlamına gelmez.

Koruma geometrisi verinin ve ek koruma bilgisinin hangi bileşenlere, node’lara veya hata alanlarına dağıtıldığını anlatır. Striping işi paralel birimlere bölebilir fakat tek başına koruma sağlamaz. Mirroring aynı verinin birden fazla kopyasını tutar; okuma seçenekleri ve basit recovery sağlayabilir, kapasite maliyeti yüksektir. Parity temelli RAID veri ve parity’yi stripe’lara dağıtır; kapasite verimliliği artarken özellikle küçük write için read-modify-write veya full-stripe davranışı, hesaplama ve backend I/O etkisi doğabilir. Erasure coding veriyi data ve parity chunk’larına ayırarak yapılandırılabilir kapasite-dayanıklılık dengesi sunar. “RAID 6 güvenlidir” tek başına mimari gereksinim değildir. Kaç data ve parity birimi var, stripe/chunk boyutu ne, koruma hangi drive/node/rack/site hata alanına yayılıyor, aynı anda kaç ve hangi hata tolere ediliyor, rebuild sırasında kalan koruma ve performans ne, ikinci hata veya latent sector error nasıl ele alınıyor? Aynı isim farklı implementasyonlarda farklı stripe genişliği, spare politikası ve distributed rebuild davranışı gösterebilir. SNIA Data Protection Best Practices, erasure coding’i özellikle büyük ve dağıtık sistemlerde storage verimliliği, performans ve rebuild hızı arasında yapılandırılabilir denge olarak tanımlar. Ancak parity sayısını artırmak bedelsiz değildir: usable oran düşer, encode/decode işi ve failure halinde okuma yolu artabilir. Geometri iş yükü, failure domain, recovery süresi ve operasyon yeteneğiyle birlikte seçilir.

Basit geometri hesabı tasarımın başlangıcıdır. N data + M parity şemasında teorik kullanılabilir oran N/(N+M)’dir; formatlama, metadata, spare, sistem rezervi, copy-on-write ve data services bundan ayrıca düşer. Mirror factor iki ise teorik fiziksel kapasitenin yarısı veri kopyasına ayrılır. Bu oranlar yalnız kapasiteyi gösterir; küçük write maliyeti, rebuild trafiği, controller/cache davranışı ve dağıtım sınırı ayrıca ölçülür. Rebuild süresi yalnız drive kapasitesinin nominal bant genişliğine bölünmesi değildir. Kaynak ve hedef medyanın gerçek boş kapasitesi, production yükü, rebuild throttling, ağ/backend paylaşımı, kaç chunk okunacağı, data reduction/encryption yolu ve hata sırasındaki ek retry sonucu etkiler. Daha büyük drive daha az cihazla kapasite sağlayabilir; tek arızada yeniden oluşturulacak veri ve risk penceresi büyüyebilir. Degraded durumda müşteri hizmetinin p99 latency ve throughput hedefi korunmuyorsa “veri kaybolmadı” tek başarı ölçütü değildir. Spare da etiketten ibaret değildir. Dedicated veya distributed spare kapasitesi, hangi hata alanında bulunduğu, otomatik rebuild tetikleme koşulu, replacement tedarik süresi ve yeniden korumalı duruma dönüş hedefi yazılır. Scrub/patrol read ve integrity doğrulaması latent hataları daha önce bulabilir; frekans ve performans etkisi operasyon planına girer.

Arven’in ERP, görüntü ingest ve kullanıcı dosyası yükleri için tek bir all-flash pool önerilmiştir. Aday tasarım 8+2 parity/EC, yüzde 10 spare ve controller write cache içerir. Sunum 500.000 IOPS ve 1 PB effective capacity yazar; test beş dakika sürmüş, veri seti cache’ten küçük kalmıştır. Koruma chunk’larının hangi drive enclosure veya node’lara dağıldığı, bir node kaybında p99 sonucu, cache failover ve rebuild süresi belgelenmemiştir. Pre-Sales önce üç veri yolunu çizer. ERP VM’den filesystem, virtual disk, host multipath, iki fabric, storage front-end, controller cache, backend ve media’ya; görüntü uygulamasından object gateway, network, metadata ve data node’larına; kullanıcı paylaşımından SMB/NFS katmanı ve file controller’a kadar ölçüm noktaları işaretlenir. Her katmana timeout, queue, retry, sahip ve saat kaynağı eklenir. Ortak controller, uplink veya backend port görülürse üç hizmetin birbirini etkileyebileceği varsayımı test edilir. Ardından medya ve cache matrisi kurulur. ERP için 70 dakikalık küçük random/senkron write profili; ingest için büyük sequential/object akışı; file servisi için metadata ve küçük dosya karışımı, normal ve tepe dolulukta çalıştırılır. Cache sıcak ve soğuk, destage/GC aktif, bir path ve bir controller kayıp durumları ayrı load point’tir. Başarı yalnız array IOPS değil, ERP p99 commit, ingest tamamlanma süresi ve dosya operasyonu percentile’ıdır. Koruma kararı 8+2 etiketini açar: data/parity yerleşimi, enclosure/node/rack hata alanı, usable hesabı, spare, rebuild throttling, degraded performans ve ikinci hata riski kaydedilir. Mirror alternatifi kapasite maliyetiyle; daha geniş veya dar EC alternatifi rebuild, latency ve fault-domain etkisiyle karşılaştırılır. RAID/EC’nin backup olmadığı ve ayrı kurtarma kanıtı gerektirdiği karar notunda korunur.