Güncellendi:
Hipervizör, fiziksel kaynakların sanal makineler tarafından kullanılmasını sağlayan sanallaştırma katmanıdır. İşlemci zamanı, bellek eşlemesi, aygıt erişimi ve konuk sistemlerin birbirinden ayrılması bu yapının parçasıdır. Yönetim araçları hipervizörle birlikte çalışır; ancak yönetim paneli ile sanallaştırma katmanı aynı bileşen değildir.
Görseli büyüt →
Hipervizör hangi kaynakları yönetir?
Konuk işletim sistemi sanal işlemci, bellek ve aygıtlarla çalışır. Hipervizör ve ilişkili bileşenler bu istekleri fiziksel kaynaklara eşler. Donanım sanallaştırma uzantıları bu süreçte kullanılabilir; desteklenen işlemci, firmware ayarı ve sürücüler gerçek platforma göre doğrulanmalıdır.
Sanal ağ ve disk erişimi yalnız hipervizör kodundan oluşmaz. Sanal switch, aygıt modeli, konuk sürücüleri ve depolama altyapısı da davranışı belirler. Sorun incelemesinde konuk işletim sistemindeki yüksek beklemeyi doğrudan fiziksel disk arızası veya CPU yetersizliği olarak yorumlamayın.
Tip 1 ve Tip 2 sınıflaması
Tip 1, hipervizörün donanım üzerinde temel sanallaştırma katmanı olduğu yaklaşımı; Tip 2 ise bir ana işletim sistemi üzerinde çalışan hosted yaklaşımı anlatır. ESXi ve Hyper-V genellikle Tip 1, VirtualBox ise hosted yaklaşım örnekleri olarak ele alınır.
KVM, Linux çekirdeğinin sanallaştırma yeteneklerini kullanır ve çoğunlukla QEMU gibi kullanıcı alanı bileşenleriyle birlikte çalışır. Linux yönetim ortamının görünmesi tek başına bu mimariyi basitçe Tip 2 yapmaz. Hyper-V’de de yönetim işletim sistemi bir root partition içinde çalışır; arayüzün masaüstü görünümünden hipervizör sınıfı çıkarılmaz.
Performansın kaynağını doğru ölçün
Bir sanal makineye daha fazla vCPU atamak her durumda daha iyi sonuç vermez. Ana makinenin yükü, işlemci zamanlaması, NUMA yerleşimi ve uygulamanın paralellik yeteneği önemlidir. Bellek baskısı, swap, disk gecikmesi ve ağ kuyrukları birlikte izlenmelidir.
Overcommit bazı iş yüklerinde kaynak kullanımını artırabilir; bütün konukların aynı anda yoğunlaşması halinde hizmet kalitesini etkileyebilir. Kapasite kararını yalnız toplam atanmış RAM veya ortalama CPU grafiğiyle vermeyin. Yoğun dönemleri ve arıza sonrası kalan kaynaklarla çalışma ihtiyacını da hesaplayın.
İzolasyon güçlüdür fakat mutlak değildir
Konukların ayrılması güvenlik tasarımının önemli bir katmanıdır. Yine de hipervizör, aygıt sürücüleri ve yönetim arayüzleri güncel tutulmalıdır. Yönetici hesabının ele geçirilmesi birden fazla konuğu etkileyebilir. En az yetki, ayrı yönetim ağı, güçlü kimlik doğrulama ve denetlenebilir değişiklik süreçleri gerekir.
Paylaşılan klasör, pano, aygıt passthrough veya dışa açılan yönetim portu gibi kolaylıkların oluşturduğu sınırı inceleyin. Bir özelliği açmadan önce hangi veri ve erişim yolunu genişlettiğini belirleyin. Snapshot ve yedeklerin erişim hakları da konuk verisi kadar önemlidir.
Seçim için bir kontrol listesi
- Gerekli konuk işletim sistemleri ve sürücü desteği var mı?
- Donanım uyumluluğu, lisans ve destek kapsamı uygun mu?
- Yedekleme, geri yükleme ve yükseltme süreçleri işletilebilir mi?
- Yönetim API’si ve izleme araçları ekibin çalışma biçimine uyuyor mu?
Ürünleri mutlak hız veya güvenlik sırasına koymak yerine aynı donanım ve temsili uygulamayla değerlendirin. İşletim sorumlulukları ve kurtarma süreci de teknik seçimin parçasıdır.
Sık sorulan sorular
- Hipervizör ile sanal makine aynı şey mi?
-
Hipervizör kaynakları sanallaştıran katmandır; sanal makine bu kaynakları kullanan konuk ortamdır.
- Yönetim işletim sistemi görünüyorsa ürün Tip2 midir?
-
Hayır. Özellikle KVM ve Hyper-V gibi mimarilerde gerçek katmanlar incelenmelidir; yalnız kullanıcı arayüzüne bakarak sınıflama yapılmaz.
Sonraki adım
Konuk ortamın yaşam döngüsünü sanal makine rehberi ile; hosted çalışma modelini VirtualBox açıklaması ile inceleyin.
