Çok Katmanlı Sizing ve Dayanıklılık Hesabı

Ön koşul: İş Yükü Ölçümü ve Kapasite Zarfı dersindeki Arven iş birimi, normal/tepe/burst profili ve kanıt defterini okuyabilmelisin. Bu derste CPU, bellek, depolama ve ağ kapasitesini tek ortalamaya indirgemeden ayrı katmanlarda hesaplayacak; bakım ve bir failure domain kaybında kalan kapasiteyi sınayacak; darboğaz ve POC kararını yazacaksın. Yaklaşık 30 dakika hesap modeli, 25 dakika vaka uygulaması, 13 dakika kontrol önerilir. İlk adım ölçülen talebi kaynak tüketimine çevirmektir. Sipariş başına CPU zamanı, bellek çalışma kümesi, yazılan veri ve taşınan bayt bilinmiyorsa cihaz miktarı kesin sayı olarak çıkmaz. İşlem başına tüketim yükle değişebilir: cache doluluğu, kilit yarışması, sıkıştırma ve kuyruk davranışı yüzünden doğrusal varsayımı test et. Her katsayı için ölçüm kaynağı, konfigürasyon, yazılım sürümü ve tarihin bulunması gerekir.

Depolama hesabında iki eksen vardır: saklanacak kullanılabilir veri miktarı ve iş yükünün istediği performans. Kapasite için başlangıç veri hacmi, günlük değişim, indeks ve metadata, retention, snapshot, çoğaltma, yedekleme politikası, yeniden oluşturma alanı ve büyüme ufku ayrı yazılır. Ham TB doğrudan kullanılabilir TB değildir; koruma düzeni, spare, format ve platform overhead'i etkiler. Performans için okuma-yazma oranı, blok boyutu, rastgele/sıralı erişim, IOPS, MB/s ve uçtan uca latency birlikte ölçülür. 4 KB rastgele yazma ile büyük sıralı backup aynı IOPS sayısında aynı kaynak yükünü yaratmaz. Sadece kapasiteyi karşılayan bir yapı p99 yazma gecikmesini kaçırabilir. Veri tabanı log yazısı, snapshot silinmesi ve rebuild sırasında tepe kaynağın ne kadar kaldığı ayrıca test edilir. Sonuç farklı katmanlarda darboğaz ve desteklenebilir konfigürasyon aralığı olarak yazılır.

Normal durumda yeterli görünen toplam kapasite arıza sonrasında yetersiz kalabilir. Önce failure domain'i tanımla: sunucu, rack, switch, güç hattı, storage controller veya site. Bir domain kaybında kalan kaynakların gerçekten iş yükünü taşıyıp taşımadığını katman katman hesapla. N+1 etiketi hangi N ve hangi hizmet için geçerlidir? Tek düğüm kaybı sonrası kalan CPU, bellek ve I/O ile p99 gecikme kabulü birlikte gösterilmelidir. Kapasite yalnız toplam üzerinden bölünmez; veri yerleşimi, anti-affinity, VM restart zamanı ve belirli düğümdeki bağlı lisans/cihaz sınırı önemlidir. Aynı arıza sırasında rebuild, re-sync, backup ve kuyruğun boşalması kaynak ister. 'Kalan iki düğüm yüzde 50' hesabı, yeniden kurulum yükü veya kurulum yerleşimi eklenmezse eksiktir. Failover'ın ne kadar sürede devreye girdiği RTO ile, hangi verinin kaybolabileceği RPO ile ayrıca karşılaştırılır.

Her katman için talep, kullanılabilir kapasite ve kalan marjı normal, tepe, arıza ve bakım halinde ayrı hesapla. Headroom yüzdesi, tasarım kuralı olarak seçilen ve testle doğrulanan bir sınırdır; evrensel yüzde yoktur. Kırılma noktası ilk doyan kaynak veya SLO'yu ilk bozan davranıştır. Doygunluk sadece yüzde 100 kullanımda görülmez: kuyruk gecikmesi, scheduler ready süresi, storage p99 veya ERP throttling daha erken hizmeti düşürebilir. Modelde bir değişkenin hatası sonucu nasıl değiştiriyor diye duyarlılık hesabı yap. Örneğin işlem başına CPU süresi yüzde 25 artarsa hangi senaryoda karar değişir? ERP limiti düşerse portal kapasitesi boşa mı çıkar? En kritik ve en az güvenilir varsayımları POC önceliğine al. Nihai çıktı tek SKU listesi değil, senaryolara göre darboğaz sırası, koşullu kapasite aralığı ve hangi ölçümle revize edileceği olmalıdır.