Seçim Rehberi · Bulut Altyapısı
Object Storage Sınıfı Seçimi: GCS, S3 ve Azure Blob
Depolama sınıfı seçimi aylık GB fiyatıyla bitmez. Okuma sıklığı, retrieval ücreti, minimum saklama, işlem sayısı ve restore gecikmesi toplam maliyeti değiştirir. Google Cloud…
Teknik gözden geçirme:
Mimari ve çalışma modeli
Depolama sınıfı seçimi aylık GB fiyatıyla bitmez. Okuma sıklığı, retrieval ücreti, minimum saklama, işlem sayısı ve restore gecikmesi toplam maliyeti değiştirir. Google Cloud Coldline/Archive, S3 arşiv seçenekleri ve Azure Archive aynı erişim modeline sahip değildir.
Google Cloud arşiv sınıfları ile Azure/S3 offline arşiv kiplerini aynı “soğuk” etiketi altında eşitlemeyin. S3 içinde de instant ve restore gerektiren seçenekler vardır. Region, redundancy ve API uyumunu seçilen sınıfın resmi belgesinde doğrulayın.
Lifecycle geçişi ile silme ayrı kurallardır. Çok kısa retention veya sık restore ihtiyacı arşiv tasarrufunu yok edebilir. Ransomware kurtarması için tüm veri setinin okunacağı günü maliyet ve süre hesabına dahil edin.
- 1Erişim ve retention
- 2Sınıf ve region
- 3Retrieval/restore testi
- 4Toplam maliyet kararı
Tasarım parametreleri
- Erişim profili
- Aylık okunan GB ve nesne sayısını birlikte ölçün; küçük nesne istekleri maliyeti değiştirebilir.
- RTO
- Restore bekleme, indirme ve uygulama açılışını toplayın.
- Saklama süresi
- Minimum süre ve erken silme koşullarını mevcut tarifeden kontrol edin.
Platformlardaki uygulama karşılıkları
Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.
| Platform | Sınıf ailesi örnekleri | Kontrol noktası |
|---|---|---|
| Google Cloud | Standard/Nearline/Coldline/Archive | Online erişim, retrieval ve minimum süre |
| AWS | S3 Standard/IA/Glacier seçenekleri | Instant veya restore tabanlı kip |
| Azure | Hot/Cool/Cold/Archive | Archive rehydration ve redundancy |
Hesap ve uygulama örneği
10 TB veri ayda yüzde 1 okunuyorsa 100 GB retrieval varsayılır; ancak yıllık bir tam restore 10 TB daha ekler. TCO modelini depolama GB-ay + okuma GB + request + egress + erken silme olarak kurun. Bu örnek tarife içermeyen hesap modelidir, fiyat teklifi değildir.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Arşiv ucuz ama fatura yüksek | Retrieval/işlem/erken silme etkisi. | Fatura kalemlerini gerçek erişim metriğiyle eşleştirin. |
| RTO sağlanmıyor | Restore beklemesi veya link sınırı. | Tüm veri seti için restore+indirme süresini ölçün. |
Kabul ve doğrulama kontrolleri
- Güncel tarifeyi region bazında okuyun.
- Okuma GB ve nesne sayısını ölçün.
- Minimum saklamayı doğrulayın.
- Tam restore pilotu yapın.
- Lifecycle silmesini ayrı kontrol edin.
- Üç platformu aynı erişim varsayımıyla karşılaştırın.
İlgili kavramlar
Maliyet ölçümünün sınırı
Maliyeti yalnız satın alma veya aylık kaynak bedeli olarak görmeyin. Lisans kapsamı, depolama, veri çıkışı, yedekleme, destek, işletim emeği ve arıza etkisi farklı kalemlerdir. Hesap için aynı hizmet seviyesi, kapasite ve süreyi kullanın; ucuz görünen seçenek başka bir yükümlülüğü dışarıda bırakıyor olabilir. Tahmin ile gerçekleşeni kaynak veya iş birimi bazında karşılaştırın. Taahhütlü modelde kullanım azalması, esnek modelde ise kontrolsüz büyüme riskini değerlendirin. Fiyat ve lisans koşullarını karar günündeki resmî belgelerden doğrulayı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.
RTO ve uçtan uca kurtarma süresi
RTO, bir hizmetin olaydan sonra ne kadar sürede kullanılabilir hale gelmesi gerektiğini ifade eder. Yedek dosyasının indirilmesi veya sanal makinenin açılması bu sürenin yalnız bir bölümüdür. Olayı tanıma, onay, altyapı hazırlığı, veri aktarımı, uygulama açılışı ve iş biriminin doğrulaması ayrı zaman kalemleri olarak kaydedilmelidir. Bir testin kronometresini hangi olayda başlatıp bitirdiğinizi açıkça yazın. Aynı teknik geri dönüş süresi, bağımlılık veya erişim beklenmesi nedeniyle farklı iş süreçlerinde farklı kesinti süresine dönüşebilir.
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.
Kalıcılaştırma ve güç kaybı
Commit edilmiş verinin güç kaybından sonra korunması veritabanı, işletim sistemi, dosya sistemi, kontrolcü ve diskin yazma garantilerinin birleşimine bağlıdır. Yazma önbelleği ve flush davranışını bilmeden performans için güvenlik ayarlarını kapatmayın. Güç kaybı korumalı depolama faydalıdır fakat bütün zincirin doğru yapılandırıldığını tek başına kanıtlamaz. Üretim yerine kontrollü laboratuvarda arıza ve recovery testi yapın. Veri bütünlüğünü örnek dosya açılmasıyla değil, uygulama kayıtları ve desteklenen tutarlılık kontrolleriyle doğrulayın.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alı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.