Ana içeriğe geç

SecuraWall.com

E-posta güvenliği ve sürekliliği

Keşfedin
Teknik Rehber

Sunucu Boyutlandırma Rehberi
CPU, RAM, Depolama, RAID ve Büyüme Payı

Sunucu seçimi yalnız çekirdek sayısı veya toplam RAM üzerinden yapılmamalıdır. Uygulama karakteri, eş zamanlı kullanıcı, disk I/O, sanallaştırma oranı, yedekleme penceresi ve büyüme beklentisi birlikte analiz edilmelidir.

1. İş Yükünü Tanımlayın

Veritabanı, dosya sunucusu, ERP, sanal makineler veya uygulama sunucuları farklı CPU, RAM ve disk karakteristiğine sahiptir.

2. CPU ve RAM

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.

3. Storage ve RAID

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.

4. Network ve Yedekleme

Yedekleme penceresi, replika trafiği, storage bağlantısı ve kullanıcı erişimi network arayüzlerinin ve uplink kapasitesinin planlanmasını etkiler.

KONTROL LİSTESİ

Teklif veya Proje Öncesinde Hazırlayın

  • Uygulama / iş yükü listesi
  • Mevcut CPU / RAM kullanımı
  • Disk kapasitesi ve IOPS ihtiyacı
  • RAID ve disk tipi
  • Sanallaştırma oranı
  • Network hızı
  • Yedekleme penceresi
  • Büyüme payı
ÖNEMLİ

Rehber Genel Bilgilendirme Amaçlıdır

Gerçek sizing, lisans, güvenlik veya mimari kararı; mevcut altyapı, üretici destek koşulları ve proje gereksinimleri değerlendirilerek verilmelidir.

FAQ

Sık Sorulan Sorular

Bu rehber ürün seçimi için tek başına yeterli mi?

Hayır. Rehber genel değerlendirme kriterlerini açıklar. Gerçek ürün, lisans veya mimari kararı mevcut altyapı ve ihtiyaç analiziyle verilmelidir.

Teklif almadan önce hangi bilgileri hazırlamalıyım?

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.

Mimari ve çalışma modeli

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.

  1. 1Hizmet hedefi
  2. 2Temsilî ölçüm
  3. 3CPU/RAM/storage tasarımı
  4. 4Pilot ve rezerv doğrulaması
Her donanım kararını gözlenen iş yükü ve hedef gecikmeyle ilişkilendirin.

Tasarım parametreleri

Ölçüm dönemi
Vardiya, ay sonu, backup ve bakım işlerini kapsayın; kısa bir boş saat örneği kapasite planı değildir.
Büyüme ve SLA
Kapasite artışını yanıt süresi ve arıza rezerviyle ilişkilendirin; tek bir CPU/RAM oranını tüm uygulamalara uygulamayın.
Yoğun saat iş yükü
CPU, bellek, disk ve ağ ölçümlerini aynı zaman aralığında toplayın. Bir kaynak yüzdesi tek başına sizing kararı verdirmez.
N-1 kapasitesi
Bir bileşen kaybedildiğinde kalan kapasiteyi hesaplayın. Normal durumda boş pay görünmesi arızada yeterli kapasite bulunduğunu kanıtlamaz.
Uyumluluk zinciri
CPU, firmware, sürücü, hypervisor ve konuk uygulamaların destek koşullarını birlikte inceleyin.
İşletim rezervi
Backup, migration, bakım ve büyüme aynı kaynaklarla yarışır. Rezervi yalnız ortalama yük üzerinden belirlemeyin.

Hesap ve uygulama örneği

Ö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.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Kaynaklar düşük ama SLA tutmuyorKilit, 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ükleniyorKapasite 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ştiSü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.

Kabul ve doğrulama kontrolleri

  1. Her donanım kararını gözlenen iş yükü ve hedef gecikmeyle ilişkilendirin.
  2. Yoğun saat yükünü ve bakım işlerini birlikte temsil eden test çalıştırın.
  3. Bir host veya bağlantı kaybında hizmet ve veri yazmasını doğrulayın.
  4. Konuk işletim sistemi ve uygulama desteğini resmî matriste kontrol edin.
  5. Yeniden başlatma sonrasında aygıt, servis ve depolama sağlığını doğrulayın.
  6. Kapasite hesabının ham ve kullanılabilir değerlerini ayrı saklayın.

İlgili kavramlar

NUMA yerelliği

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

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.

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.

IOPS ve blok boyutu

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 ile kurtarma ayrımı

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 ve failback

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.

Birincil teknik dokümantasyon

Editoryal Şeffaflık · Kim · Nasıl · Neden

Bu Rehber Nasıl Hazırlandı?

KİM?

Doz Teknoloji Teknik Ekibi

Bu rehber, Doz Teknoloji teknik ekibinin kurumsal IT projelerinde kullandığı değerlendirme kriterleri temel alınarak hazırlanmıştır.

Doz Teknoloji hakkında
NASIL?

Teknik Kriterler + Birincil Kaynaklar

CPU, 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ı.

NEDEN?

Karar Kalitesini Artırmak

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.

SON TEKNİK GÖZDEN GEÇİRME

İçerik ve birincil kaynaklar yeniden kontrol edildi.

İlgili Sonraki Adımlar

Konuyu teknik rehber, ürün/lisans veya proje senaryosu üzerinden ayrıntılı olarak inceleyin.

Bu Rehberle İlgili Kurumsal Çözümler

Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.

Teknik İhtiyacınızı Birlikte Değerlendirelim

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
Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!