Sanallaştırma Hizmeti ve Hypervisor Mimarisi

Ön koşul: compute, bellek/NUMA, storage ve SAN veri yollarını; workload, p99, RTO/RPO ve failure domain kavramlarını açıklayabilmelisin. Bu dersin sonunda “sunucuları sanallaştıralım” talebini ölçülebilir bir platform hizmetine çevirecek; host, hypervisor, VM ve guest sınırlarını ayıracak; yönetim, kontrol ve veri yollarını tek mimaride gösterecek; Arven için kaynak, erişim, dayanıklılık ve yaşam döngüsü TBD’leri taşıyan baseline hazırlayabileceksin. Yaklaşık 29 dakika anlatı, 16 dakika vaka/uygulama ve 10 dakika kontrollerdir. CPU scheduling, memory reclamation, HCI dağıtık storage ve kesin cluster sizing’i sonraki derslerdedir.

Sanallaştırma, fiziksel CPU, bellek, network ve storage kaynaklarını yazılım aracılığıyla birden çok izole çalışma ortamına sunar. Amaç yalnız sunucu sayısını azaltmak değildir. Asıl çıktı; uygulamaların belirli performans, kullanılabilirlik, güvenlik, taşınabilirlik ve operasyon koşullarında çalıştığı yönetilebilir bir platform hizmetidir. “Yüzde kaç sanallaştırabiliriz?” sorusu workload uygunluğu ve hizmet eşiği bilinmeden cevaplanamaz. Talep önce iş yükü portföyüne ayrılır. Her uygulama için iş kritiklik, kullanıcı zamanı, CPU/memory davranışı, I/O ve ağ profili, lisans bağımlılığı, donanım erişimi, latency, RTO/RPO, bakım penceresi ve destek matrisi kaydedilir. Fiziksel sunucunun düşük ortalama CPU’su tek başına iyi aday olduğunu göstermez; kısa ama kritik burst, büyük bellek working set’i, cihaz passthrough’u veya sıkı vendor desteği kararı değiştirebilir. Platform sözleşmesi VM oluşturmanın ötesindedir: kaynak havuzu, placement, yedeklilik, network segmentasyonu, datastore erişimi, image/template yönetimi, backup, izleme, patch, kapasite eşiği ve sahiplik. Provisioning süresi bir çıktı olabilir; fakat kapasite ve yaşam döngüsü kontrolü yoksa hız, VM sprawl ve görünmez maliyet üretir. Her VM’in sahibi, amacı, hizmet sınıfı, veri sınıfı ve son gözden geçirme tarihi bulunmalıdır. Başarı ölçütleri kullanıcı sonucuna bağlanır. Normal ve tepe iş yükünde p95/p99, transaction veya batch bitişi; host kaybında yeniden başlama/failover, veri ve hizmet etkisi; bakımda kalan kapasite; backup ve restore sonucu; güvenlikte yönetim erişimi ve tenant/workload isolation ölçülür. Konsolidasyon oranı sonuç değil, bu kapılardan sonra oluşan bir tasarım değeridir.

Hypervisor veya VMM, fiziksel donanım kaynaklarına erişimi aracılık eden ve birden çok VM’in aynı hostta çalışmasını sağlayan yazılım katmanıdır. NIST, hypervisor platformunu CPU, memory, network ve storage kaynaklarını sanallaştıran modüller bütünü olarak ele alır. VM; kendisine sunulan vCPU, sanal bellek, sanal NIC, disk/controller ve firmware arayüzleri üzerinde guest OS ile uygulamayı çalıştıran mantıksal sistemdir. Type 1 hypervisor doğrudan server platformunda çalışır; Type 2, genel amaçlı bir host işletim sistemi üzerinde uygulama katmanı olarak yer alır. Kurumsal veri merkezi kararında etiket ezberinden çok veri yolu, saldırı yüzeyi, destek, patch, driver/device modeli ve operasyon ayrımı önemlidir. “Bare metal” ifadesi guest’in fiziksel kaynağa sınırsız ve doğrudan sahip olduğu anlamına gelmez; hypervisor hâlâ kaynak erişimini planlar ve aracılık eder. CPU sanallaştırması guest’e vCPU sunar; vCPU fiziksel core değildir. Bellek sanallaştırması guest fiziksel adreslerini host belleğine eşler. Sanal NIC, sanal switch/bridge ve fiziksel uplink üzerinden haberleşir. Sanal disk; dosya, volume, LUN veya dağıtık nesne üzerinde yer alabilir ve guest’e block device görünümü verir. Her soyutlama esneklik sağlar; aynı zamanda queue, cache, mapping, telemetry ve failure domain zincirine yeni katman ekler. Isolation varsayımdan çıkarılıp kontrole çevrilir. Hypervisor farklı VM’lerin runtime erişimini ayırır; fakat ortak CPU/cache, bellek, NIC, storage, yönetim hesabı, template veya backup alanı ortak neden yaratabilir. Guest OS güvenliği hypervisor güvenliğinin yerine geçmez. Yönetim arayüzü ayrı erişim, güçlü kimlik, en az ayrıcalık, log, patch ve güvenli iletişim ister. Passthrough veya doğrudan device erişimi performans sağlayabilir; mobility, HA, paylaşım ve operasyon özelliklerini sınırlayabilir.

Sanallaştırma platformu üç bakışla okunur. Yönetim düzlemi kullanıcı, API, envanter, politika, alarm ve lifecycle işlemlerini taşır. Kontrol düzlemi placement, cluster üyeliği, kaynak kararı, HA orkestrasyonu ve sanal ağ/storage durumunu yönetir. Veri yolu ise VM’in gerçek CPU instruction, memory erişimi, network frame’i ve storage I/O’sunun geçtiği zincirdir. Ürüne göre bileşen sınırları değişebilir; ayrım troubleshooting ve güvenlik için korunur. Yönetim sunucusunun kaybı çalışan VM’leri hemen durdurmayabilir; ancak yeni VM, migration, alarm veya HA kararı etkilenebilir. Tersine yönetim ekranının yeşil olması veri yolundaki uplink, storage path veya guest I/O’nun sağlıklı olduğunu göstermez. Her düzlem için dependency, kimlik, sertifika/DNS/NTP, network, veri deposu, yedekleme ve recovery yöntemi yazılır. VM I/O yolu katmanlıdır. Guest uygulama ve OS isteği sanal device/driver’a, hypervisor queue’suna, fiziksel NIC/HBA’ya, network/SAN fabric’e ve storage hizmetine gider. Sanal networkte aynı hosttaki iki VM trafiği fiziksel switche çıkmadan kalabilir; geleneksel fiziksel gözlem noktaları bu east-west trafiği görmeyebilir. Güvenlik politikası, flow log ve packet capture noktası gerçek yola göre seçilir. Cluster bir hizmet mekanizmasıdır, uygulama HA’sının eş anlamlısı değildir. Host failure algılama, VM restart veya live migration platform davranışıdır; uygulama state, transaction consistency, timeout ve yeniden bağlanma ayrı sonuçlardır. Shared storage veya dağıtık storage, quorum/witness, management ve network bağımlılıkları failure matrix’e eklenir. Bakımda bir host çıkarıldığında kalan CPU, memory, network ve storage kapasitesi tepe yükünü taşımalıdır.

Arven’in beş-altı yıllık sanallaştırma altyapısı modernize edilecektir. İlk talep “daha az host, daha çok VM ve kesintisiz geçiş”tir. Ancak envanterde workload sahibi, tepe penceresi, reservation/limit, NUMA yerleşimi, sanal ağ akışı, datastore yolu, backup/restore sonucu, lisans bağımlılığı ve support end date eksiktir. Mevcut ortalama kullanım yeni cluster sizing’i için yeterli değildir. Ekip önce workload register oluşturur: iş sonucu, kritik zaman, vCPU/memory demand, working set, network/I/O profili, p99, RTO/RPO, guest/device ve lisans desteği, veri sınıfı, owner ve güven düzeyi. Powered-off, template, test ve orphan VM’ler ayrılır. Tahsis ile gerçek tüketim; normal ile eşzamanlı tepe; uygulama büyümesi ile sprawl ayrı tutulur. Fiziksel-mantıksal harita host socket/NUMA, memory, NIC/HBA, uplink, SAN/storage ve yönetim bağımlılıklarını her VM hizmet sınıfına bağlar. İki NIC veya iki storage path aynı kart, PCIe root, switch, fabric, controller ya da rack gücünü paylaşıyorsa ortak neden kaydedilir. Yönetim ve backup bileşenlerinin hangi platform üzerinde çalıştığı, platform kaybında nasıl geri getirileceği gösterilir. Kabul planı normal ve tepe workload, tek host kaybı, bakım/drain, uplink/path kaybı, yönetim düzlemi kaybı, backup/restore ve kontrollü migration içerir. VM restart/migration süresi ile uygulama transaction, p99, timeout ve veri tutarlılığı aynı zaman çizgisinde ölçülür. İlk ders ürün veya HCI seçmez; ölçüm sözleşmesi, adaylık, bağımlılık, risk ve TBD paketi üretir. Arven’in sonraki kararı bu baseline üzerinde ilerler. İkinci ders vCPU scheduling, NUMA, memory overcommit ve noisy neighbor davranışını; üçüncü ders HCI compute-network-storage veri yolunu ve dağıtık failure domain’i; son ders cluster sizing, N+1/N+2, yaşam döngüsü, migration, TCO ve koşullu öneriyi tamamlayacaktır.

Bir sonraki ders baseline’daki kaynak sayılarını gerçek davranışa çevirir. vCPU scheduling ve ready/steal benzeri bekleme, socket/core/NUMA yerleşimi, memory reservation/limit, reclamation ve swapping, overcommit ile noisy neighbor, passthrough ve kaynak politikaları normal, tepe ve host kaybı senaryolarında incelenecektir. Arven’in workload register’ı bu ölçümlerle güncellenecektir.