Yeni depolama yatırımı çoğu zaman kaç terabayt alınacağı sorusuyla başlar. Oysa aynı kapasite, dosya paylaşımı, sanal makine ve uygulama arşivi için aynı sonucu vermez. Erişim yöntemi, gecikme, veri büyümesi ve kurtarma hedefleri tasarımı değiştirir. NAS, SAN veya nesne depolama seçimini yalnızca kapasite tablosuyla yapmak, sonraki işletim maliyetini görünmez bırakabilir.
Bu yazı belirli bir marka veya ürün boyutlandırması önermez. Amaç, depolama tekliflerini iş yüküne göre karşılaştırabilmeniz için soruları netleştirmektir. Aynı kurumda birden fazla modelin birlikte kullanılması normaldir. Tek bir platformun bütün veri türlerini aynı verimle karşılayacağını varsaymak yerine kullanım biçimlerini ayırın.
Dosya, blok ve nesne erişimini ayırın
Dosya depolama, klasör ve dosya mantığıyla çalışan paylaşımlar için kullanılır. Blok depolama, işletim sistemi veya uygulamaya birim sunan farklı bir erişim modelidir. Nesne depolama ise veriyi nesne kimliği ve metadata üzerinden ele alır; uygulamalar çoğunlukla API ile erişir. Red Hat'in depolama modelleri açıklaması, bu kavramsal ayrımı ele alır.
NAS ve SAN isimleri, bu erişim modellerinin altyapı tarafındaki düzenleriyle ilişkilidir; birebir kapasite veya performans etiketi değildir. Belirli bir uygulamanın desteklediği protokol ve tutarlılık beklentisi önce incelenmelidir. Bir paylaşımı nesne depolamaya taşımak, uygulamanın aynı dosya yolu mantığıyla çalışmaya devam edeceğini garanti etmez.
1. İş yükünün erişim şeklini ölçün
Veri büyük dosyalar hâlinde mi okunuyor, çok sayıda küçük işlem mi yapılıyor? Okuma ve yazma oranı nasıl? Aynı anda kaç kullanıcı veya uygulama erişiyor? Ortalama veri miktarının yanında yoğun saatleri ve arka plan işlerini de görün. Yedekleme, indeksleme veya raporlama aynı depolama kaynaklarını kullanıyor olabilir.
Performans değerlendirmesinde yalnızca en yüksek IOPS değerine bakmayın. İşlem boyutu, gecikme ve aktarım hızı sonucu değiştirir. Üreticinin ölçtüğü koşullarla sizin iş yükünüz farklı olabilir. Temsilî bir test senaryosu ve kabul ölçütü hazırlamak, teklifleri daha anlamlı biçimde karşılaştırır. Ölçüm süresini uygulamanın gerçek davranışını görecek kadar seçin.
2. Kullanılabilir kapasiteyi açıkça hesaplayın
Ham disk kapasitesiyle uygulamaya sunulabilecek alan aynı değildir. Koruma düzeni, yedek alan, metadata ve diğer sistem ihtiyaçları kullanılabilir kapasiteyi etkiler. Sıkıştırma veya tekilleştirme gibi özelliklerin sağlayacağı kazanç da veri türüne bağlıdır. Her veri kümesinde aynı oranı garanti kabul etmeyin.
Büyüme payını yalnızca gelecek yılın toplam terabaytı olarak hesaplamayın. Snapshot birikimi, yeni uygulamalar ve saklama süresinin uzaması da alan tüketebilir. Kapasite uyarıları bir sorumluya ulaşmalı ve genişletme kararı için yeterli zaman bırakmalıdır. Son anda disk eklemek, her platformda kesintisiz veya aynı maliyetle yapılabilen bir işlem değildir.
3. Hata alanlarını ve bakım davranışını inceleyin
Disk koruması, cihazın veya lokasyonun tamamının kaybını karşılamaz. Denetleyici, ağ yolu, güç ve yönetim bileşenlerinin ortak arıza alanlarını görün. Yedekli görünen parçalar aynı bağımlılığa bağlıysa beklenen dayanıklılık oluşmayabilir. Tasarım çizimini bu bağımlılıkları gösterecek düzeyde hazırlayın.
Bakım sırasında erişimin nasıl süreceğini de sorun. Firmware güncellemesi, disk değişimi veya kapasite genişletme süreçlerinin destek koşulları ve işletim sorumlusu belli olmalıdır. Sadece arıza hâlinde ne olacağını değil, normal bakımda ne gerektiğini bilmek toplam hizmet kalitesini etkiler. Destek sözleşmesini teknik mimariden ayrı değerlendirmeyin.
4. Snapshot, replikasyon ve yedeği aynı şey saymayın
Snapshot kısa süreli geri dönüşte faydalı olabilir. Replikasyon ikinci sisteme veri aktarımını sağlayabilir. Yedekleme ise ayrı saklama ve kurtarma amaçlarını karşılar. Birinin varlığı diğer bütün gereksinimlerin karşılandığını göstermez. Aynı yönetim hesabının bütün kopyaları silebilmesi de ayrıca değerlendirilmesi gereken bir risktir.
Kabul testini örnek bir dosyanın açılmasıyla bitirmeyin. Uygulamanın tutarlı veriyle geri getirilebildiğini ve hedef sürede kullanılabildiğini gösterin. Büyük hacimli bir geri yüklemede ağ ve depolama kapasitesi belirleyici olabilir. Gerekli iş süresini ölçmeden yalnızca yedekleme penceresine göre karar vermeyin.
5. Güvenlik ve yönetim erişimini tasarlayın
Depolama yönetim arayüzleri, veri erişim yetkilerinden ayrı korunmalıdır. Yönetici hesabı, uygulama hesabı ve son kullanıcı erişimi farklı ihtiyaçlara sahiptir. Yetki devri ve kayıt tutma düzeni belirleyin. Paylaşımın çalışması için geniş izin vermek kolaydır; sonrasında hangi erişimin gerçekten gerekli olduğunu ayıklamak daha zor olabilir.
Şifreleme kullanılıyorsa anahtarın kimde olduğu ve kurtarma sırasında nasıl erişileceği açıklanmalıdır. Bir özelliğin ürün kutusunda bulunması, doğru yapılandırıldığı veya ihtiyaç anında kullanılabileceği anlamına gelmez. Yönetim ve kurtarma erişimlerini yetkili kişilerle sınayın; gerçek sırları dokümana açık metin eklemeyin.
Teklif karşılaştırmasına eklenebilecek ölçütler
- İş yüküyle eşleşen protokol ve üretici desteği.
- Kullanılabilir kapasite, büyüme ve performans varsayımları.
- Bakım, destek ve hata alanları.
- Yedekleme ile ölçülmüş geri yükleme davranışı.
- Yönetim yetkileri, lisanslar ve işletim emeği.
CieloSync ile sunucu ve depolama çözümlerini uygulamalarınızın gerçek ihtiyacına göre değerlendirebilirsiniz. Mevcut veri yapınızı paylaşın; kapasiteyi, performansı ve kurtarmayı aynı tasarımda konuşalım.