1. İş Yükünü Tanımlayın
Veritabanı, dosya sunucusu, ERP, sanal makineler veya uygulama sunucuları farklı CPU, RAM ve disk karakteristiğine sahiptir.
Veritabanı, dosya sunucusu, ERP, sanal makineler veya uygulama sunucuları farklı CPU, RAM ve disk karakteristiğine sahiptir.
Mevcut kullanım, pik yükler ve sanallaştırma overhead'i dikkate alınmalıdır. Yalnız bugünkü ortalamaya göre sizing yapılması büyüme alanını daraltabilir.
Kapasite kadar IOPS, gecikme, disk tipi ve RAID seviyesi önemlidir. RAID veri erişilebilirliğine katkı sağlar ancak bağımsız yedek yerine geçmez.
Yedekleme penceresi, replika trafiği, storage bağlantısı ve kullanıcı erişimi network arayüzlerinin ve uplink kapasitesinin planlanmasını etkiler.
Gerçek sizing, lisans, güvenlik veya mimari kararı; mevcut altyapı, üretici destek koşulları ve proje gereksinimleri değerlendirilerek verilmelidir.
Hayır. Rehber genel değerlendirme kriterlerini açıklar. Gerçek ürün, lisans veya mimari kararı mevcut altyapı ve ihtiyaç analiziyle verilmelidir.
Kullanıcı/cihaz sayısı, mevcut ürün veya altyapı, kapasite, lisans süreleri ve beklenen büyüme bilgileri teklif sürecini hızlandırır.
Server sizing hizmet hedefini ölçülebilir kaynak gereksinimine çevirir. Kullanıcı sayısı tek başına CPU, RAM veya IOPS seçtirmez. Uygulama iş yükü, yoğun saat, büyüme, bakım ve arıza durumu birlikte değerlendirilir. Düşük ortalama kullanım tek çekirdek, bellek çalışma kümesi veya depolama beklemesini gizleyebilir.
Örnek keşifte 7 günlük ölçüm yoğun saat ve backup penceresini kapsasın. CPU çekirdek dağılımı, RAM baskısı, disk gecikmesi ve ağ aktarımını aynı zaman çizelgesinde inceleyin. Kapasite büyümesini ve arıza rezervini ayrı satırda hesaplayın; yüzde pay eklemek ölçümün yerine geçmez.
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Kaynaklar düşük ama SLA tutmuyor | Kilit, tek thread veya dış bağımlılık olabilir. | İşlem süresini sunucu metrikleri ve uygulama beklemeleriyle eşleştirin. |
| Düşük CPU kullanımına rağmen uygulama yavaş | Depolama, kilit, tek çekirdek veya zamanlama beklemesi toplam CPU değerinde görünmeyebilir. | Uygulama gecikmesini çekirdek, disk ve hypervisor beklemeleriyle eşleştirin. |
| Arıza sonrası host aşırı yükleniyor | Kapasite planı normal dağılım için yapılmış, N-1 durumu dışarıda kalmış olabilir. | Kontrollü arıza testinde kalan RAM, CPU ve depolama gecikmesini ölçün. |
| Değişiklikten sonra performans kötüleşti | Sürücü, firmware, NUMA yerleşimi veya kaynak ataması değişmiş olabilir. | Aynı iş yükünde önce/sonra karşılaştırma yapın; bir değişkeni bir seferde değiştirin. |
NUMA sistemlerde işlemci, kendisine yakın bellekle uzak düğüm belleğine farklı maliyetle erişebilir. Bir sanal makinenin vCPU ve bellek boyutu, fiziksel düğüm kapasitesi ve hypervisor yerleştirmesiyle birlikte değerlendirilir. Daha fazla vCPU vermek her zaman hız kazandırmaz; yerellik kaybı ve zamanlama beklemesi performansı düşürebilir. Fiziksel topolojiyi, VM içindeki görünen topolojiyi ve gerçek iş yükünün bellek davranışını birlikte kaydedin. Değişikliği aynı yük altında önce/sonra karşılaştırın; yalnız CPU yüzdesi yerine uygulama gecikmesini ve uzak bellek etkisini inceleyin.
Kaynak rekabeti, birden fazla iş yükünün aynı CPU, bellek, disk veya bağlantıyı paylaşırken birbirini bekletmesidir. Boş görünen toplam kapasite, tek bir sıcak çekirdek veya tek kuyruk üzerindeki darboğazı gizleyebilir. Aynı anda çalışan backup, antivirüs taraması, indeks bakımı ve kullanıcı trafiğini zaman çizelgesinde karşılaştırın. Kaynak eklemeden önce darboğazın yerini doğrulayın. Testte bir işi tek başına ve diğerleriyle birlikte çalıştırarak paylaşılan kaynağın etkisini ayırın; ortalama kullanım kadar yoğun saatlerdeki gecikmeyi de raporlayın.
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.
IOPS saniyedeki I/O işlem sayısını, MB/s ise taşınan veri miktarını anlatır. Aynı IOPS sayısı farklı blok boyutlarında çok farklı bant genişliği üretir. Örneğin 10.000 işlem/s × 4 KiB yaklaşık 39,1 MiB/s eder. Okuma/yazma oranı, rastgele veya sıralı erişim ve veri koruma mekanizması sonucu değiştirir. Bir benchmark sonucunu üretim uygulamasına doğrudan taşımak yerine gerçek blok dağılımını ve eşzamanlılığı ölçün. Diskin yüksek IOPS göstermesi, uygulama yanıtının iyi olduğu anlamına gelmez; gecikme de birlikte incelenmelidir.
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Failover, hizmetin başka bir bileşene geçmesidir; failback, tercih edilen konuma geri alınmasıdır. İkisi aynı risk ve işlem sırasına sahip olmayabilir. DNS güncellemesi, yönlendirme, oturumlar, veri geriliği ve uygulama bağımlılıkları kullanıcı kesintisini belirler. Otomatik geçişin hangi koşulda tetiklendiğini, yanlış alarmda ne olacağını ve geri dönüş onayını tanımlayın. Arızayı yalnız sanal makineyi kapatarak test etmek tüm hata türlerini kapsamaz. Ağ, depolama ve yönetim katmanı arızalarının ayrı etkilerini ölçün.
Bu rehber, Doz Teknoloji teknik ekibinin kurumsal IT projelerinde kullandığı değerlendirme kriterleri temel alınarak hazırlanmıştır.
Doz Teknoloji hakkındaCPU, RAM, storage, sanallaştırma ve büyüme payı değerlendirmesi güncel Windows Server / Hyper-V gereksinimleri ve ölçek sınırlarıyla karşılaştırıldı.
Sunucuyu yalnız çekirdek veya RAM sayısına göre değil, iş yükü, IOPS ve gelecekteki kapasite ihtiyacına göre boyutlandırmak.
İçerik ve birincil kaynaklar yeniden kontrol edildi.
Konuyu teknik rehber, ürün/lisans veya proje senaryosu üzerinden ayrıntılı olarak inceleyin.
Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.
Mevcut altyapı, kullanıcı veya iş yükü bilgilerini paylaşın; ürün, lisans veya proje kapsamını ihtiyaca göre netleştirelim.
Teknik Talep Oluşturun