Data Services, Kullanılabilirlik ve Veri Bütünlüğü

Ön koşul: storage erişim modelini, iş yükü profilini, kapasite katmanlarını, veri yolunu ve koruma geometrisini çıkarabilmelisin. Bu dersin sonunda snapshot, clone, replication, thin provisioning, compression ve deduplication özelliklerini isim listesi yerine davranış sözleşmesiyle değerlendirebilecek; crash-consistent ile application-consistent kopyayı ayırabilecek; storage HA ve QoS iddialarını hata senaryosu ve iş ölçüsüyle sınayabilecek; veri bütünlüğü, şifreleme, anahtar yönetimi, izolasyon ve restore assurance gereksinimlerini tek hizmet politikasında birleştirebileceksin. Yaklaşık 30 dakika anlatı ve örnek, 18 dakika Arven uygulaması, 10 dakika bilgi kontrolleridir. Ayrıntılı backup/cyber resilience ve DR tasarımı sonraki modüllerin kapsamındadır.

Data service bir kutucuk değil, belirli girdide gözlenebilir davranış ve sınırdır. Thin provisioning mantıksal alanı fiziksel tüketimden ayırır; overcommit oranı, fiziksel eşik, otomatik büyüme ve tükenme halinde uygulama davranışı tanımlanmalıdır. Compression ve deduplication fiziksel tüketimi azaltabilir; oran veri türü, şifreleme, değişim hızı, chunk sınırı ve ölçüm dönemine bağlıdır. QoS kaynak paylaşımını yönetebilir; minimum, maximum veya priority semantiği ve kaynak kıtlığında uygulanma noktası bilinmeden “performans garantisi” denmez. Snapshot belirli bir point-in-time görünüm oluşturur. Uygulama yazmaya devam ederken alınan storage-consistent snapshot, storage’ın kendi metadata ve write-order bütünlüğünü koruyabilir; uygulamanın çok volume, log ve transaction durumunun birlikte kurtarılabilir olduğunu otomatik kanıtlamaz. Crash-consistent kopya elektrik kesintisi benzeri duruma; application-consistent kopya uygulamanın flush/quiesce ve transaction kurallarına göre tanımlanır. Consistency group birden fazla volume için write-order ilişkisini korumaya yardım edebilir; uygulama ajanı ve restore prosedürü yine doğrulanır. Clone bağımsız veya paylaşım tabanlı read/write kopya üretmek için kullanılabilir. İlk anda kapasite verimli görünen copy-on-write clone, değişen bloklarla fiziksel alan ve performans tüketir. Snapshot zinciri uzadıkça metadata, silme/birleştirme süresi ve failure impact büyüyebilir. Her özellik için oluşturma süresi, RPO anlamı, bağımlı metadata, source silinirse davranış, performans overhead’i, retention, yetki, izleme ve geri dönüş testi yazılır.

Storage kullanılabilirliği “dual controller” veya “iki path” etiketiyle tamamlanmaz. Host initiator, multipath policy, fabric A/B, front-end port, controller, cache mirror, backend port, enclosure, media ve yönetim/anahtar servislerinin hata alanları izlenir. İki mantıksal yol aynı HBA, switch, cable route, controller veya power domain’de birleşebilir. Failover sırasında timeout ve retry sırası uygulamanın kendi timeout’undan uzunsa veri kaybı olmasa da hizmet kesilir. Active-active ifadesi de ölçüm ister. Her iki controller veya path aynı anda I/O işliyor mu, belirli volume için optimized/non-optimized yol var mı, yük dağıtımı hangi algoritmayla, bir controller kaybında kalan port/backend/cache kapasitesi tepe yükünü karşılıyor mu? Firmware upgrade veya path maintenance planlı failure senaryosudur. Başarılı ping ya da volume görünürlüğü transaction’ın hedef süre içinde tamamlandığını kanıtlamaz. Availability hedefi senaryo, zaman ve hizmet ölçüsü taşır. Path kaybı, controller reboot, disk/node rebuild, fabric bakım, yönetim servisi veya key manager erişimsizliği ayrı olaylardır. Detection, fencing, failover, retry, rescan ve application recovery zinciri ölçülür. Planlı bakımda uygulama latency, hata oranı ve throughput eşiği; başarısızlık halinde rollback veya escalation sahibi yazılır.

Paylaşımlı storage’da noisy neighbor yalnız başka volume’un yüksek IOPS üretmesi değildir. Ortak front-end port, controller CPU, cache, backend group, media, metadata servisi, replication linki, snapshot job veya rebuild aynı kaynağı tüketebilir. QoS politikası hangi katmanda uygulanıyorsa yalnız o katmandaki talebi şekillendirir. Volume’a IOPS maximum koymak backend parity veya metadata işini, latency percentile’ını ya da diğer ortak kaynakları doğrudan garanti etmeyebilir. Minimum, maximum ve priority farklı sözleşmelerdir. Maximum komşuyu sınırlayabilir; minimum yalnız yeterli fiziksel kaynak ve doğru admission control varsa anlamlıdır; priority kıtlıkta göreli sıra sağlayabilir, mutlak latency sunmayabilir. IOPS limiti I/O size değiştiğinde MB/s etkisini, bandwidth limiti küçük random I/O’daki controller işini farklı gösterir. Politika birimi, burst davranışı, enforcement window ve ihlal telemetrisi belirtilir. QoS testi tek volume ile yapılmaz. Kritik ve baskın komşu yükler birlikte çalıştırılır; snapshot, replication veya rebuild background işi eklenir; normal ve degraded topoloji ayrı ölçülür. Başarı, policy ekranındaki değer değil kritik uygulamanın p95/p99 ve hata hedefidir. Kaynak yetersizse politika kapasite yaratmaz; workload admission, ayrı pool veya mimari ayrıştırma gerekebilir.

Veri bütünlüğü yalnız bitlerin medyada bulunması değildir. İstek doğru tenant, host, volume, file veya object’e yönlenmeli; yazma sırası ve acknowledged state korunmalı; aktarım ve at-rest verisi yetkisiz değişiklikten algılanmalı; silent corruption, misdirected write, stale copy ve uygulama tutarsızlığı için kontrol ve recovery yolu bulunmalıdır. Checksum hangi katmanda hesaplanıyor, nerede saklanıyor, okuma sırasında ne zaman doğrulanıyor ve mismatch halinde hangi sağlam kopyadan onarılıyor soruları sorulur. End-to-end integrity iddiası kapsam taşır. Drive ECC medya içi hataları, transport CRC aktarım hatalarını, filesystem veya object checksum üst katman verisini kapsayabilir. Bir kontrol diğerinin yerine geçmez; checksum’ın veriyle aynı hata alanında bozulması, yanlış anahtar veya hatalı uygulama yazmasının geçerli checksum üretmesi mümkündür. Scrub/patrol read hatayı erken bulabilir; sıklığı, performans etkisi, alarm ve repair sonucu izlenir. Restore assurance bütünlük zincirinin sonucudur. Kopyanın varlığı, katalogda görünmesi veya checksum doğrulaması uygulamanın ayağa kalktığını kanıtlamaz. Seçili kopya izole ortamda restore edilir; application recovery, schema/log replay, dependency, kimlik, DNS, secret/key, kullanıcı kabulü ve hedef zaman ölçülür. Hangi corruption veya ransomware senaryosunda hangi temiz noktaya dönüleceği ve kopyanın saldırgandan nasıl ayrıldığı yazılır.

NIST SP 800-209 storage güvenliği için erişim kontrolü, izolasyon, restoration assurance ve encryption’ı birlikte ele alır. Data at rest şifreleme media kaybı veya alt katman erişimine karşı koruma sağlayabilir; data in transit istemci, storage öğeleri ve replication yollarındaki aktarımı; administrative session şifrelemesi yönetim düzlemini kapsar. “Encryption enabled” cümlesi hangi veri, metadata, log, snapshot, replica ve backup kopyasının hangi anahtarla korunduğunu belirtmelidir. Anahtar yönetimi storage’dan ayrı bir hizmet bağımlılığıdır. Anahtar üretimi, dağıtımı, rotasyonu, yedeklenmesi, erişim ayrılığı, iptal ve imha süreci; key manager erişilemezken okuma/yazma ve reboot davranışı; disaster recovery’de anahtarın geri gelme sırası sınanır. Anahtar kaybı veriyi erişilemez kılabilir, aynı admin’in hem storage hem key policy’yi değiştirebilmesi separation-of-duties riskidir. İzolasyon yalnız VLAN değildir. Host/initiator mapping, LUN masking, namespace/export policy, object bucket/tenant, management role, service account, API, snapshot/clone paylaşımı ve monitoring/log erişimi birlikte değerlendirilir. Test, yetkili kaynaktan doğru erişimi ve yetkisiz host/tenant/admin yolundan reddi gösterir. Encryption erişim yetkisini düzeltmez; yetkili fakat kötü niyetli işlem şifreli veriyi silebilir veya bozabilir. Immutability ve retention kontrolü varsa kimlerin policy’yi değiştirebildiği, saat kaynağı, bypass/privileged delete yolu ve gerçek restore ayrıca doğrulanır.

Arven için önerilen storage “snapshot, synchronous replication, encryption, immutable copy ve QoS destekli” diye sunulur. Ancak ERP üç volume, görüntü uygulaması object bucket ve kullanıcı dosyaları file share kullanır. Snapshot’lar aynı yönetim hesabıyla silinebilir, ERP application-consistency ajanı test edilmemiştir. Replication linki yoğun saatte lag üretir; “synchronous” etiketi yalnız belirli pool için geçerlidir. Key manager aynı sanallaştırma cluster’ında çalışır. QoS policy yalnız IOPS maximum tanımlar; ingest MB/s ile backend’i doyurabilir. Arven storage hizmet politikası her veri hizmeti için ayrı yazılır. ERP consistency group, uygulama quiesce, p99 ve restore süresi; object ingest version/retention, metadata bütünlüğü ve throughput; file share ACL, directory/metadata latency ve kullanıcı restore senaryosu taşır. Snapshot, clone ve replication için source bağımlılığı, retention, lag/RPO, failover ve restore kanıtı kaydedilir. Backup ve cyber recovery kopyaları ayrı modülün kontrol alanı olarak tutulur. HA matrisi path, controller, backend, key manager ve yönetim servisi kayıplarını içerir. Normal ve degraded yükte ERP transaction, ingest ve file operasyonu birlikte çalıştırılır. QoS birimleri ve ortak kaynaklar eşlenir; politika kapasite yaratmıyorsa ayrı pool veya workload window seçeneği değerlendirilir. Maintenance ve firmware upgrade de planlı failure testi olarak eklenir. Güvenlik ve bütünlük matrisi data, metadata, snapshot, replica ve log kapsamını gösterir. At-rest, in-transit ve admin session encryption; key ownership ve recovery; host/tenant/admin isolation; checksum/scrub ve repair; retention policy change ile privileged delete negatif testleri yazılır. Son karar, özellik sayısından değil bütün hizmetin belirlenen hata ve saldırı senaryolarında ölçülen sonucundan çıkar.