VMware sunucu, çoğunlukla VMware sanallaştırma yazılımını çalıştıran fiziksel hostu veya bu host üzerinde çalışan sanal makineyi ifade eder. Doğru seçim, yalnızca işlemci çekirdeği sayısına bakılarak yapılmaz; sanal makinelerin toplam bellek ihtiyacı, depolama erişim biçimi, ağ trafiği ve büyüme payı birlikte değerlendirilir. Önce iş yüklerini sınıflandırın, sonra host kaynaklarını bu davranışa göre eşleştirin.
Günlük kullanımda bu ifade iki farklı şeyi gösterebilir. Birincisi, VMware’in hipervizörünü çalıştıran fiziksel sunucudur. Hipervizör, aynı fiziksel donanım üzerinde birbirinden ayrılmış sanal makineler oluşturup bunların işlemci, bellek, disk ve ağ kaynaklarını yönetir. İkincisi ise bu ortamda çalışan, işletim sistemi ve uygulamaları bulunan sanal makinedir. Teklif veya mimari değerlendirmesi yaparken hangisinin kastedildiğini netleştirmek gerekir.
Bir fiziksel host üzerinde birden fazla sanal makine çalışacaksa karar noktası, toplam sanal kaynakları fiziksel kaynaklarla karşılaştırmaktır. Ancak sanal makinelerin tüm vCPU değerlerini doğrudan fiziksel çekirdek sayısına eşitlemek doğru değildir; her makinenin aynı anda ne kadar işlem yaptığı ve kısa süreli yoğunlukların ne kadar sürdüğü de önem taşır. Sürekli işlemci kullanan veritabanı veya analiz iş yüklerinde daha düşük yoğunlaştırma oranı tercih edilirken, çoğunlukla bekleyen hafif uygulamalar aynı hostta daha verimli toplanabilir.
Önce sanal makineleri kullanım biçimine göre ayırın: sürekli hesaplama yapanlar, kısa süreli yoğunlaşanlar ve düşük etkinlikte çalışanlar. Sürekli çalışan uygulamalar toplam fiziksel işlem kapasitesine yaklaşıyorsa daha fazla sanal makine eklemek yerine fiziksel çekirdek payını koruyun. İzleme ekranında işlemci bekleme veya hazırda bekleme süresi yükseliyorsa sorun yalnızca vCPU sayısı değildir; host üzerindeki rekabet de incelenmelidir. Bu belirti görülürse gereksiz vCPU tahsislerini azaltmak veya iş yüklerini farklı hostlara dağıtmak, tüm sanal makinelere rastgele işlemci eklemekten daha güvenli bir adımdır.
Bellek için önce her sanal makinenin işletim sistemi ve uygulaması tarafından gerçekten kullanılan miktarı belirleyin. Fiziksel belleği sanal makinelerin tanımlı bellek toplamına denk kabul etmek, hipervizörün kendi ihtiyacını ve beklenmeyen artışları gözden kaçırabilir. Bir uygulamanın bellek kullanımı düzenli olarak yükseliyor ve hostta serbest pay azalıyorsa önce hangi makinenin artışı oluşturduğunu bulun; yalnız o iş yükünün gerektirdiği kadar bellek artırın. Host düzeyinde bellek baskısı oluşuyorsa yeni sanal makine eklemek yerine kapasite artırımı veya iş yükü dağıtımı değerlendirilmelidir.
Dosya boyutu ile depolama performansı aynı ölçüt değildir. Büyük arşivleri seyrek okuyan bir sanal makine için kapasite öncelikli olabilir; çok sayıda küçük veritabanı işlemi yapan bir makine için gecikme ve I/O işlemlerini karşılayabilme kapasitesi daha belirleyici olur. Bu nedenle depolama kararında yalnızca toplam terabaytı değil, okuma-yazma düzenini, eşzamanlı sanal makine sayısını ve yedekleme sırasında oluşan ek trafiği değerlendirin.
Ağ tarafında sanal makinelerin toplam bağlantı hızını yazmak başlangıç için yararlıdır, fakat tek başına yeterli değildir. Yönetim trafiği, sanal makine trafiği, depolama erişimi ve yedekleme aynı fiziksel bağlantıyı paylaşıyorsa yoğun saatlerde birbirini etkileyebilir. Uygulama dışarıya az veri gönderse bile ağ üzerinden yoğun depolama veya yedekleme kullanıyorsa ayrı trafik yolları ya da daha uygun kapasite planı gerekebilir. Sağlayıcıya ait sunucu kiralama çözümleri incelenirken sanallaştırma katmanının, depolama tipinin ve ağ paylaşım modelinin ayrıca sorulması bu yüzden önemlidir.
Diyelim ki varsayımsal bir işletmede iki uygulama sunucusu, bir veritabanı sanal makinesi ve düşük trafikli bir yönetim makinesi aynı hostta çalışacak. Veritabanı düzenli disk erişimi yapıyor, uygulama sunucuları ise gün içinde kısa süreli yoğunlaşıyor olsun. Bu durumda önce veritabanına daha öngörülebilir işlemci, bellek ve düşük gecikmeli depolama payı ayırmak; ardından uygulama makinelerinin eşzamanlı yoğunluklarını izleyerek kalan kapasiteyi dağıtmak mantıklıdır. Yönetim makinesini büyük kaynaklarla tanımlamak, düşük kullanım nedeniyle kapasiteyi gereksiz yere kilitleyebilir.
İlk değerlendirmede şu gözlemleri kaydedin: host işlemci kullanımının yoğun saatlerdeki seyri, bellek baskısı belirtileri, depolama gecikmesi ve ağ arayüzlerinin doygunluğu. Uygun bir yapılandırmada yalnızca ortalama değerler değil, yoğunluk anları da kabul edilebilir aralıkta kalır; tek bir sanal makinenin artışı diğerlerinin yanıt süresini belirgin biçimde bozmamalıdır. Depolama gecikmesi yükselirken işlemci ve bellek normal görünüyorsa daha fazla CPU eklemek doğru çözüm değildir; depolama katmanını veya eşzamanlı I/O üreten iş yükünü incelemek gerekir.
VMware sunucu kararı verilmeden önce fiziksel hostun desteklediği işlemci mimarisi, bellek kapasitesi, disk bağlantı biçimi, ağ arayüzleri ve yönetim erişimi doğrulanmalıdır. Ayrıca yedekleme, bakım sırasında sanal makinelerin taşınması ve arıza halinde beklenen çalışma biçimi ayrı sorular olarak ele alınmalıdır; bunlar yalnızca daha büyük donanım seçerek otomatik biçimde çözülmez.
Pratik karar şu şekilde ilerler: İş yükü çoğunlukla düşük etkinlikteyse kaynakları kontrollü biçimde paylaşan bir host uygun olabilir; fakat birkaç uygulama aynı anda sürekli işlemci, bellek veya depolama kullanıyorsa daha fazla baş boşluğu ve dağıtılmış kapasite gerekir. Beklenen büyüme yalnızca kullanıcı sayısından ibaret değildir; veri hacmi, yedekleme penceresi ve yeni sanal makineler de hesaba katılmalıdır. İlk adım olarak mevcut sanal makinelerin yoğun saat ölçümlerini toplayın, tek bir kaynak değişkenini değerlendirin ve sonucu aynı yoğunluk koşulunda yeniden gözlemleyin.
Copyright © 2026 Tüm Hakları Saklıdır.
