İş Yükünden Storage Servisine

Ön koşul: iş hizmetini uygulama, platform, compute, network ve storage bağımlılıklarına ayırabilmeli; kanıtın zamanını, kaynağını ve güven düzeyini kaydedebilmelisin. Bu dersin sonunda “yeni storage” talebini korunacak veri ve erişim hizmetine çevirebilecek; block, file ve object erişim modellerini ürün sınıfı gibi ezberlemeden uygulama sözleşmesiyle ayırabilecek; kapasite ile performans iddiasını farklı ölçülerle kurabilecek ve Arven için doğrulanabilir bir storage baseline hazırlayabileceksin. Yaklaşık 28 dakika anlatı ve örnek, 17 dakika uygulama, 10 dakika bilgi kontrolleridir. RAID, erasure coding, data services, ayrıntılı SAN tasarımı ve kesin ürün sizing’i sonraki derslerin kapsamıdır.

Enterprise storage bir disk veya array modelinden önce uygulamaya sunulan kalıcı veri hizmetidir. Hizmet; verinin nasıl adlandırıldığı ve erişildiği, okuma-yazma davranışı, tutarlılık beklentisi, hata halinde görünür sonuç, güvenlik sınırı, performans hedefi, kapasite büyümesi, yönetim ve yaşam döngüsüyle tanımlanır. Medya türü, controller, cache ve bağlantı bu sözleşmeyi sağlayan mimari bileşenlerdir; müşterinin iş sonucunun kendisi değildir. Block erişiminde istemci mantıksal blok adreslerine okuma ve yazma yapar; dosya sistemi veya veri tabanı gibi üst katmanlar bu blokları anlamlandırır. File erişiminde istemci dizin, dosya adı, öznitelik ve dosya protokolü işlemleriyle paylaşılan namespace’e ulaşır. Object erişiminde veri benzersiz kimlik ve metadata ile nesne olarak ele alınır; SNIA, nesnenin çoğunlukla atomik birim olduğunu ve tipik API’lerin oluşturma, okuma ve silme davranışı sunduğunu belirtir. Bu ayrım altında kullanılan diskin türünü değil, uygulamanın storage ile yaptığı sözleşmeyi anlatır. Aynı veri farklı katmanlarda farklı biçimde görünebilir. Bir sanal makine block volume üzerinde dosya sistemi kullanır; uygulama dosya görürken hypervisor block I/O üretir. Bir file servisi arka planda object veya block katmanı kullanabilir. Bu nedenle “object her zaman arşivdir”, “block her zaman hızlıdır” veya “file yalnız kullanıcı klasörüdür” gibi kısa yollar güvenilir değildir. Seçim; erişim semantiği, değişiklik örüntüsü, paylaşım, ölçek, gecikme, bütünlük ve operasyon ihtiyacına dayanır.

Storage iş yükü “kaç IOPS?” sorusundan daha geniştir. Profil; okuma-yazma oranı, istek boyutu dağılımı, random/sequential yerellik, eşzamanlılık ve queue depth, working set, cache davranışı, veri tekrar oranı, burst süresi, normal ve kritik tepe penceresi, dosya ya da nesne büyüklüğü, metadata işlemleri, senkron/asenkron yazma, flush ve durability davranışı ile tanımlanır. Aynı IOPS sayısı 4 KiB random write ile 1 MiB sequential read için bambaşka bant genişliği, gecikme ve backend işi doğurur. SNIA gerçek dünya iş yüklerini, yazılım-donanım yığınının belirli iki noktası arasında gözlenen ve değişen I/O stream’leri olarak tanımlar. Gerçek yükte istek karışımı ve talep yoğunluğu zamanla değişir. Sabit blok boyutu ve sabit queue depth kullanan sentetik test belirli sınırı ölçebilir; üretim iş yükünün doğrudan kopyası değildir. Pre-Sales sentetik sonucu reddetmez, testin hangi hipotezi hangi koşulda sınadığını ve üretim profiline nasıl bağlandığını yazar. İş birimi storage metriğinin yanında tutulur. Dakikadaki sipariş, tamamlanan rapor, paralel sanal masaüstü, saniyedeki görüntü ingest’i veya restore edilen veri miktarı teknik metriğe anlam verir. Test yükü gerçek iş hacmini sağlarken uygulama p95/p99 yanıtı ve hata oranı hedef içinde mi? Storage IOPS yükselmiş fakat kullanıcı işlemi iyileşmemişse daha yüksek sayı tek başına başarı değildir.

Gecikme ölçüm noktasıyla birlikte yazılır. Uygulamanın gördüğü süre; dosya sistemi, volume manager, hypervisor, multipath, host queue, ağ veya fabric, controller ve medya katmanlarını içerebilir. Array service time yalnız kendi sınırını gösterebilir. Linux kernel disk sayaçları tamamlanan okuma-yazma sayısını, sektörleri, I/O için harcanan zamanı ve devam eden I/O’ları sunar; `iostat` gibi araçlar bunları yorumlar. Fakat cihaz metriği uygulamanın bütün bekleme süresini tek başına açıklamaz. IOPS, MB/s veya MiB/s ve latency birlikte okunur. IOPS istek sayısını; veri transfer hızı zaman başına byte miktarını; latency tek isteğin tamamlanma süresini anlatır. Queue depth ya da concurrency arttığında toplam IOPS yükselirken her isteğin gecikmesi de artabilir. Bu nedenle “daha çok IOPS, mutlaka daha hızlı uygulama” sonucu kurulmaz. Ortalama latency kuyruk kuyruğunu ve tail etkisini saklayabilir; percentile, örnek sayısı ve yük noktası belirtilir. Ölçüm semantiği tutarlı olmalıdır. Front-end ile backend IOPS, host ile array latency, MB ile MiB, logical ile physical write ve cache hit ile media access aynı sayı değildir. Her grafikte kaynak, nesne, birim, zaman dilimi, örnekleme aralığı, aggregation, iş hacmi ve veri yolu durumu yazılır. Ölçüm noktaları ortak zaman çizgisinde eşlenmeden katmanlar arası nedensellik iddiası kurulmaz.

Kapasite görüşmesinde ilk görev sayıları aynı semantiğe çevirmektir. Raw kapasite fiziksel medyanın üretici tarafından sunulan toplamını; usable kapasite koruma, formatlama ve sistem rezervlerinden sonra veri yazılabilecek fiziksel havuzu; allocated veya provisioned kapasite hostlara atanmış mantıksal alanı; consumed kapasite gerçekten yazılmış mantıksal veriyi; free kapasite ise hangi katmanda ölçüldüğüne göre farklı boşluğu anlatabilir. Thin provisioning, snapshot, clone, compression ve deduplication bu katmanlar arasındaki ilişkiyi değiştirir. Logical capacity fiziksel olarak aynı anda var olmayan tahsisleri içerebilir. 500 TB provision edilmiş volume görmek 500 TB fiziksel tüketim anlamına gelmeyebilir; tersine 200 TB kullanıcı verisi snapshot, metadata, replication veya koruma overhead’i nedeniyle daha fazla fiziksel alan tüketebilir. Data reduction oranı veri türü, şifreleme, sıkıştırılmış içerik, değişim hızı ve ölçüm sınırına bağlıdır. Tek bir “etkin kapasite” oranı garanti gibi kullanılmaz; varsayım, örnek veri ve yeniden ölçüm koşulu yazılır. Ondalık ve ikili birimler de ayrılır. TB 10 tabanlı, TiB 2 tabanlıdır; araçlar bazen etiketi yanlış veya belirsiz kullanabilir. Kaynak sistem ve dönüşüm formülü kaydedilmeden farklı raporların yüzdeleri kıyaslanmaz. Büyüme, toplam yüzde yerine veri seti ve olay bazında modellenir: günlük ingest, retention değişikliği, yeni proje, snapshot değişim oranı, kopya sayısı ve silme gecikmesi ayrı sürücülerdir.

Arven Holding “en az 500 TB all-flash storage” ister. Mevcut rapor 310 TB provisioned, 190 TB consumed ve yüzde 72 doluluk gösterir; fakat değerlerin TB mi TiB mi, doluluğun hangi katmanda, snapshot ve replication’ın dahil olup olmadığı bilinmez. ERP ekibi ay sonunda gecikme, görüntü ekibi gelecek çeyrekte 80 TB ingest ve kullanıcı dosya ekibi küçük dosya sayısında artış bildirir. Aynı cihaz talebi altında üç ayrı veri hizmeti ve iş yükü vardır. İlk baseline ERP transaction, görüntü ingest ve kullanıcı paylaşımını ayırır. ERP için transaction hacmi, read/write ve I/O size dağılımı, commit p99, queue ve working set; görüntü için günlük veri, dosya/nesne boyutu, ingest penceresi ve MB/s; kullanıcı paylaşımı için dosya sayısı, metadata işlemleri, concurrency, namespace ve izin modeli kaydedilir. Host, network/fabric ve storage ölçümleri aynı olay penceresine bağlanır. “Array latency normal” ifadesi ölçüm noktası ve percentile olmadan kapanış kanıtı değildir. Kapasite köprüsü raw, usable, provisioned, consumed ve fiziksel tüketimi aynı birime çevirir. Snapshot değişim oranı, replication kopyası, backup staging, sistem rezervi ve beklenen data reduction ayrı satırlardır. 80 TB ingest tek seferlik proje sıçramasıdır; kullanıcı dosyası büyümesi ve ERP transaction artışı aynı doğrusal yüzdeye çevrilmez. Base, büyüme, bakım/arıza ve adverse reduction senaryoları yazılır. Erişim modeli de doğrulanır. ERP’nin block sözleşmesi, tasarım paylaşımının file namespace ve izin ihtiyacı, görüntü uygulamasının object API uyumluluğu ayrı karardır. Object seçeneği uygulama değişikliği gerektiriyorsa migration süresi, metadata eşleme, tutarlılık beklentisi ve rollback planı maliyete eklenir. Baseline sonunda ürün modeli değil; ölçülebilir hizmet sınıfları, açık TBD’ler ve seçenekleri ayıracak test planı çıkar.