Hypervisor Nedir? Sanallaştırma Katmanı Nasıl Çalışır

Hypervisor, tek bir fiziksel sunucunun donanımını birden fazla işletim sistemi arasında paylaştıran ve her birine sanki tek başına bir bilgisayarı varmış gibi bir yüzey sunan yazılım katmanıdır. Sanal makinenin içindeki Windows ya da Linux, altında paylaşılan bir donanım olduğunu bilmez: kendi diskini, kendi ağ kartını, kendi işlemcisini görür. Görmediği şey, o donanımın aynı anda on dokuz komşusuna daha sunuluyor olmasıdır.

Bunu anlamanın en kolay yolu bir iş merkezini düşünmektir, ve bu makale boyunca aynı binada kalacağız. Plazada bir kat kiralarsınız: kendi kapınız, kendi kilidiniz, kendi sayacınız ve kendi termostatınız vardır. Kapıyı kapattığınızda orası sizin ofisinizdir. Oysa bina bir tanedir; çatıdaki soğutma grubu, jeneratör, asansör ve su deposu bütün katlarla paylaşılır. Bina yönetimi size bağımsız bir bina hissi satar, ve bu bir aldatmaca değil, tam olarak satın aldığınız hizmettir.

Hypervisor da bunu yapar. Aşağıda önce bu katmanın ne olduğunu ve neden bir işletim sisteminden farklı olduğunu göreceğiz, sonra iki hypervisor tipini ayıracağız. Ardından işin en çok yanlış yapılan kısmına gireceğiz: sanal makine donanımı gerçekte nasıl görüyor, vCPU neden bir çekirdek değil, ve söz verdiğinizden fazlasını dağıtmak ne zaman çalışıp ne zaman duvara toslar. Sonra konteynerle farkını, snapshot ile yedeğin karıştırılmasını ve boyutlandırmayı ele alacağız. Şu an elinizde yavaşlayan bir sanal sunucu varsa doğrudan vCPU ve overcommit bölümüne atlayabilirsiniz. Bu makale BT sistem yönetimi hizmetimizin sanallaştırma koluna karşılık gelir.

Hypervisor Nedir, Ne İşe Yarar?

Hypervisor, donanım ile işletim sistemi arasına giren ve donanımı bölüştüren bir ara katmandır. İşi kaynak paylaştırmak kadar sınır çizmektir: her sanal makine kendi belleğine erişir, komşusununkine erişemez; kendi diskini görür, komşusunun diskini görmez.

Buradaki kilit fikir, sanallaştırmanın tamamını açıklıyor: her katman, üstündekine “sanki donanımmış gibi” bir yüzey sunar. Bu tek cümle bilgisayarın bütün yığınını sıraya dizer.

Plazada da böyledir. Arsa ve taşıyıcı sistem en altta durur. Bina yönetimi katları böler ve her kiracıya kapısı kilitli bağımsız bir alan sunar. Kiracı o alanı kendi içinde bölmelere ayırır. Bölmedeki çalışan yalnızca kendi masasını görür. Her kademe bir üstündekine, bir alt kademenin karmaşasını gizleyen sade bir yüzey verir.

Sanallaştırma Olmasaydı Ne Kırılırdı?

Sanallaştırmanın gerekçesi “modern olmak” değil, fiziksel sunucunun neredeyse hiç kullanılmamasıdır. Tek bir uygulama için alınmış bir sunucu, günün büyük bölümünde işlemcisinin küçük bir yüzdesini kullanır; geri kalanı elektrik yakar, yer kaplar ve soğutulur.

Kırılma noktasını sayıyla görelim. Yirmi ayrı uygulama için yirmi fiziksel sunucu aldığınızda, yirmi ayrı garanti süresi, yirmi ayrı güç kaynağı, yirmi ayrı yedek parça zinciri ve sistem odasında yirmi ayrı raf ünitesi yönetiyorsunuz demektir. Bunların her biri ortalama yüzde on beş doluluk ile çalışıyorsa, satın aldığınız kapasitenin yaklaşık altıda birini kullanıyorsunuz. Kalanı ödediğiniz ama hiç teslim alınmayan bir kapasitedir.

Plazanın varlık sebebi de budur. Yirmi şirketin her birine ayrı bina yapmak yerine tek bir binanın yirmi katını bölmek; jeneratörü, asansörü ve güvenliği ortaklaştırır. Kimse kendi jeneratörünü almaz, çünkü kimse jeneratörü sürekli kullanmaz.

Bunun bir de ters yüzü var ve dürüstçe söylemek gerekiyor: konsolidasyon riski yok etmez, yoğunlaştırır. Yirmi fiziksel sunucuda bir arıza bir uygulamayı durdururdu. Tek sunucuya sıkıştırılmış yirmi sanal makinede aynı arıza yirmisini birden durdurur. Bu yüzden sanallaştırma kararının ayrılmaz parçası, en az iki sunuculu bir küme ve bir sunucu düştüğünde diğerinin yükü kaldırabileceği bir kapasite hesabıdır. O hesap yapılmadıysa yapılan şey verimlilik değil, kumar.

Tip 1 ve Tip 2 Hypervisor: Fark Nerede?

Hypervisor’lar donanıma göre nerede durduklarına bakılarak ikiye ayrılır: doğrudan donanımın üstünde çalışanlar Tip 1, mevcut bir işletim sisteminin üstünde bir uygulama olarak çalışanlar Tip 2.

Farkın pratik karşılığı şudur: Tip 2’de sanal makineniz, altındaki masaüstü işletim sisteminin keyfine bağlıdır. O sistem bir güncelleme için yeniden başlarsa, bir uygulama belleği tüketirse ya da kullanıcı makineyi kapatırsa sanal makineler de gider. Tip 1’de böyle bir alt kat yoktur; hypervisor’ın kendisi en alttadır.

Kendi lab ortamım tam olarak bu ayrımın örneği. Bu sitedeki makalelerin doğrulandığı sanal makineleri (dc01, ldap01, radius01 ve diğerleri) kendi çalışma bilgisayarımda, masaüstü bir sanallaştırma ürünü üzerinde çalıştırıyorum. Bu bir tercih değil, ölçeğin doğru cevabı: makinelerin sürekli ayakta kalması gerekmiyor, gece kapanabilirler ve tek ihtiyacım onları hızlıca açıp kapatabilmek. Aynı kurguyu bir kurumun üretim ortamına koymak ise savunulamaz, çünkü altında bir masaüstü işletim sistemi ve onu her gün kullanan bir insan vardır.

Sınırın Bulanıklaştığı Yer

İki tip arasındaki çizgi göründüğü kadar keskin değil ve bunu yazmak gerekiyor, çünkü çoğu kaynak burada yanlış basitleştirme yapar.

• KVM, Linux çekirdeğinin bir modülüdür. Yani altında “bir işletim sistemi var” ama o işletim sistemi, modül yüklendiği anda kendisi hypervisor’a dönüşür. Bu yüzden KVM sınıflandırmada genellikle Tip 1 sayılır. Proxmox VE de zaten bir Debian üzerine kurulur ve KVM kullanır.
• Hyper-V rolünü etkinleştirdiğinizde Windows, hypervisor’ın altında kalmaz; hypervisor alta iner ve Windows onun üstünde ayrıcalıklı bir bölümde çalışmaya başlar. Yani rolü açtığınız an, üzerinde çalıştığınız Windows artık bir sanal makinedir.
• ESXi ise bir Linux dağıtımı değildir. Çekirdeği (VMkernel) bu iş için yazılmış, süreç zamanlayan ve bellek yöneten gerçek bir çekirdektir.

Bu ayrıntılar bilgiçlik değil, satın alma kararına dokunuyor: elinizde Windows Server lisansı varsa Hyper-V zaten o lisansın içinde geliyor, ayrı bir sanallaştırma lisansı gerekmiyor. Sürüm ve lisans modelinin ayrıntısı Windows Server rehberimizde; Linux tarafındaki karşılığı ise Ubuntu Server rehberimizde ele alınıyor.

Sanal Makine Donanımı Nasıl Görür? vCPU, RAM ve Overcommit

Sanal makinenin gördüğü donanım gerçek değildir, bir tahsistir. Bu cümle makalenin en pahalı yanlış anlamasını çözer: sanal makineye dört vCPU vermek, ona dört fiziksel çekirdek ayırmak demek değildir.

Mekanizma şöyle işler. Hypervisor’ın bir zamanlayıcısı vardır ve fiziksel çekirdekleri zaman dilimlerine bölerek sanal makineler arasında paylaştırır. Bir sanal makine işlem yapmak istediğinde, hypervisor onu bir fiziksel çekirdeğe yerleştirir; işi bitince ya da süresi dolunca çekirdek başkasına geçer. vCPU bir donanım parçası değil, sıraya girme hakkıdır.

Plazadaki karşılığı otoparktır. Bina yönetimi yüz araçlık otoparkı iki yüz kiracıya satabilir, çünkü herkes aynı gün araçla gelmez. Sistem çalışır, hatta verimlidir. Ama bir sabah herkes birden gelirse kapıda kuyruk oluşur ve o kuyruk otoparkın küçük olmasından değil, sözün fazla verilmiş olmasından doğar.

Overcommit: Fazla Söz Vermek Ne Zaman Çalışır?

Overcommit, fiziksel olarak var olandan daha fazla kaynağı sanal makinelere dağıtmaktır ve sanallaştırmanın ekonomisi buna dayanır. Ama üç kaynak aynı davranmaz, ve karıştırıldığında sonuçları da aynı olmaz.

Ayrımın sebebi mekanizmada. CPU zamanda bölünebilir: bir çekirdek bir milisaniye birine, sonraki milisaniye diğerine hizmet eder ve kimse bunu fark etmez. Bellek bölünemez: bir sanal makinenin kullandığı bellek sayfası o an başkasına verilemez. Hypervisor sıkışınca önce boştaki sayfaları geri toplar, aynı içerikli sayfaları teklerde birleştirir, sonra sıkıştırır; bunların hiçbiri yetmezse belleği diske yazar. Son adıma gelindiğinde performans azalmaz, çöker, çünkü nanosaniyelerle ölçülen bellek erişimi milisaniyelerle ölçülen disk erişimine dönüşmüştür.

Depolamada ise tuzak alanla ilgili. İnce tahsis (thin provisioning) ile sanal makinelere toplamda diskinizde olmayan kadar alan söz verebilirsiniz; makineler yavaş yavaş doldukça o söz gerçek alana dönüşür. Ünite dolduğu anda üzerindeki sanal makineler yazma yapamaz ve durur. Bu, izlemesi en kolay ama en sık gözden kaçan arızalardan biridir.

Neden Çok vCPU Vermek Makineyi YAVAŞLATIR?

Şimdi sezgiye en aykırı gelen yere geldik: bir sanal makineye daha fazla vCPU vermek onu çoğu zaman hızlandırmaz, yavaşlatır.

Sebebi zamanlayıcının çalışma biçimidir. Sekiz vCPU’lu bir sanal makine iş yapacağı zaman hypervisor, sekiz fiziksel çekirdeğin yaklaşık aynı anda boşalmasını bekler. Yoğun bir sunucuda sekiz çekirdeğin aynı anda boşalması, dört çekirdeğin boşalmasından belirgin biçimde daha seyrek olur. Yani makineniz daha fazla kaynak istediği için sıranın arkasına düşer.

Otoparkta kendi aracınızla gelirseniz tek boş yer yeterlidir. Sekiz kişilik bir servisle gelirseniz yan yana sekiz yer boşalmasını beklersiniz ve o kuyrukta daha uzun durursunuz.

Bunun ölçülebilir bir karşılığı var: sanal makinenin çalışmaya hazır olduğu halde çekirdek beklediği süre. Bu değerin yüzde birkaçın üstüne çıkması, o makinenin kaynak beklediğini söyler ve genel kabul, yüzde onu aşan değerlerin müdahale gerektirdiğidir. Pratik kural nettir: az vCPU ile başlayın, ölçün, gerekiyorsa artırın. Ters yönde ilerlemek, yani bol vererek başlayıp sorun çıkınca kısmak, hem daha zordur hem de o sırada kullanıcı şikayet ediyordur.

Sanal makinelerin durumunu ve kaynak kullanımını görmek için platformun kendi aracını kullanırsınız. Hyper-V tarafında:

Get-VM | Select-Object Name, State, CPUUsage, MemoryAssigned, Uptime
Get-VMHost | Select-Object LogicalProcessorCount, MemoryCapacity

KVM tabanlı bir sistemde karşılığı:

virsh list --all
virsh dominfo dc01
virsh nodeinfo

Bu çıktılarda bakılacak sıra şudur:

1. Makine sayısı ve durumu: kaç sanal makine tanımlı, kaçı gerçekten çalışıyor. Kapalı ama tanımlı makineler disk alanı tüketmeye devam eder.
2. Toplam tahsis edilen vCPU / fiziksel çekirdek oranı: bu oran overcommit seviyenizdir ve tek başına iyi ya da kötü değildir, iş yükü türüne bağlıdır.
3. Atanan bellek toplamı ile sunucunun fiziksel belleği: bellekte overcommit’e CPU’daki kadar rahat girilmez, bu iki sayı birbirine yakınsa uyarı işaretidir.
4. Çalışma süresi: aylardır yeniden başlatılmamış bir sanal makine yama almamış olabilir.

Sanal Makine mi Konteyner mi? Sınır Nerede Çizilir?

Konteyner, sanal makinenin küçüğü değildir; farklı bir katmanda çalışan farklı bir şeydir. Sanal makine kendi işletim sistemini taşır ve hypervisor ona sahte donanım verir. Konteyner ise kendi işletim sistemini taşımaz, altındaki sistemin çekirdeğini komşularıyla paylaşır; çalışma zamanı ona sahte bir işletim sistemi görüntüsü verir.

Plazada fark şudur. Sanal makine, kendi kapısı ve kilidi olan bağımsız bir kattır: içeride ne yaptığınız komşuyu ilgilendirmez, hatta binanın ana giriş kurallarından bağımsız kendi kurallarınızı işletirsiniz. Konteyner ise açık ofiste bölme duvarıyla ayrılmış bir alandır: kendi masanız ve kendi dolabınız vardır, ama ısıtma, aydınlatma ve giriş kapısı ortaktır.

Bu ortaklığın iki doğrudan sonucu var ve ikisi de karar verirken belirleyicidir:

• Çekirdek paylaşıldığı için sınır daha incedir. Sanal makine arasındaki duvar donanım seviyesinde çizilir; konteynerler arasındaki duvar işletim sisteminin kendi mekanizmalarıyla çizilir. İzolasyon ihtiyacı yüksekse, özellikle farklı güven seviyelerindeki iş yükleri yan yana duracaksa, sanal makine daha güvenli sınırdır.
• Çekirdek paylaşıldığı için işletim sistemi seçilemez. Linux çekirdeği üzerinde Windows konteyneri çalışmaz. Sanal makinede böyle bir kısıt yoktur, çünkü her makine kendi işletim sistemini getirir.

Buna karşılık konteynerin kazandırdığı şey ağırlıktır: kendi işletim sistemini taşımadığı için saniyeler içinde başlar ve aynı donanımda kat kat fazlası çalışır. Doğru soru “hangisi daha iyi” değil, “bu iş yükü kendi işletim sistemine ihtiyaç duyuyor mu” olmalıdır. Bir Domain Controller, bir veritabanı sunucusu ya da satın aldığınız bir kurumsal uygulama sanal makine ister. Sık güncellenen, yatayda çoğaltılan bir uygulama bileşeni konteynere daha uygundur.

Sahadaki dürüst cevap da şu: KOBİ ölçeğindeki çoğu kurumda konteynere gerçek bir ihtiyaç yoktur ve konteyner platformu kurmak, çözdüğünden fazla yönetim yükü getirir. İhtiyaç, uygulama geliştiren ya da sık sürüm çıkaran ekiplerde başlar.

Snapshot, Yedek ve Canlı Göç: Karıştırılan Üçlü

Bu üçü aynı yerde durur, benzer görünür ve birbirinin yerine kullanıldığında gerçek veri kaybı üretir. Ayrımı net koymak gerekiyor.

Snapshot Bir Yedek Değildir

Snapshot, sanal makinenin belirli bir andaki halini geri dönülebilir kılan bir işaretlemedir. Mekanizması şudur: snapshot alındığı anda makinenin asıl diski salt okunur hale gelir ve o andan sonraki bütün yazmalar yeni bir fark diskine gider. Geri dönmek istediğinizde fark diski atılır, asıl disk olduğu gibi yerinde durmaktadır.

Bu mekanizma iki sonucu doğuruyor ve ikisi de sahada acı çektiriyor:

• Fark diski büyür ve makine yavaşlar. Snapshot ne kadar uzun yaşarsa fark diski o kadar şişer; her okuma zincirin halkalarını dolaşmak zorunda kalır. Haftalarca unutulmuş bir snapshot, sebebi bulunamayan yavaşlamanın klasik kaynağıdır.
• Silmek de bedava değildir. Snapshot’ı kaldırmak, fark diskini asıl diske geri işlemek demektir ve bu ciddi bir disk yükü üretir. Yoğun saatte yapılmaz.

En önemlisi şu: snapshot aynı depolama ünitesinde durur. O ünite arızalanırsa, ya da makineye fidye yazılımı bulaşırsa, snapshot da makineyle birlikte gider. Kritik bir değişiklikten önce snapshot almak doğru bir alışkanlıktır, ama koruma değildir; sanallaştırılmış ortamın gerçek koruması için kurumsal veri yedekleme ve felaket kurtarma rehberimize bakın.

Canlı Göç: Kiracının Fark Etmediği Taşınma

Canlı göç (live migration), çalışan bir sanal makineyi kapatmadan başka bir fiziksel sunucuya taşımaktır. Mekanizması sezgiye aykırıdır ve tam da burada plaza benzetmemiz kopuyor, o yüzden nerede koptuğunu söyleyelim: gerçek bir kiracı taşınırken işini durdurur, eşyasını toplar, yeni yere kurar. Sanal makine taşınırken çalışmaya devam eder.

Bunu şöyle başarır: hypervisor makinenin belleğini, makine çalışmaya devam ederken hedef sunucuya kopyalar. Kopyalama sürerken makine bazı bellek sayfalarını değiştirir; hypervisor değişenleri tekrar gönderir, sonra kalan farkı tekrar gönderir, fark yeterince küçülene kadar bunu sürdürür. En sonda makine milisaniyeler ölçüsünde durdurulur, kalan son parça ve işlemci durumu aktarılır, makine hedefte kaldığı yerden devam eder. Kullanıcı tarafında görünen şey hiçbir şeydir.

Bunun pratik değeri büyüktür: fiziksel sunucuya bakım yapmak, belleğini büyütmek ya da yamasını geçmek için üzerindeki sanal makineleri kapatmanız gerekmez. Ama bedelsiz değildir, iki koşulu vardır. Depolamanın iki sunucudan da erişilebilir olması gerekir (ya da diskin de ayrıca taşınması gerekir), ve iki sunucunun işlemcilerinin uyumlu olması gerekir. İkinci koşul, farklı yıllarda alınmış sunucuların aynı kümede birleştirildiği ortamlarda sık sık sürpriz olarak çıkar.

Yüksek Erişilebilirlik: Sunucu Göç Edemeden Çökerse

Canlı göç planlı bir hareketti: sunucuyu siz kapatmaya karar veriyordunuz. Ama sunucu size sormadan giderse taşınacak bir şey de kalmaz, çünkü taşınacak makinenin belleği o donanımla birlikte gitmiştir. Bu durumu karşılayan mekanizmanın adı yüksek erişilebilirlik (High Availability).

Çalışma biçimi şudur: kümedeki sunucular birbirine düzenli aralıklarla yaşam sinyali gönderir. Bir sunucudan sinyal kesildiğinde küme, gerçekten çökmüş mü yoksa yalnızca ağ bağlantısı mı koptu diye ayırt etmeye çalışır (ikisini karıştırmak, aynı sanal makinenin iki yerde birden açılmasına yol açar ve bu, diski bozan bir senaryodur). Çöktüğüne karar verilirse üzerindeki sanal makineler kalan sunucularda yeniden başlatılır.

Bu cümledeki “yeniden başlatılır” ifadesi, konunun en çok yanlış anlaşılan yeridir ve satış konuşmalarında sıklıkla bulanıklaştırılır. Yüksek erişilebilirlik kesintisizlik değildir. Sanal makineler düşer, sonra başka bir sunucuda açılır; içlerindeki işletim sistemi bunu bir elektrik kesintisi gibi yaşar. Aradaki süre çoğunlukla dakikalarla ölçülür ve o dakikalarda hizmet yoktur. Kazanılan şey kesintinin sıfırlanması değil, saatlerin dakikaya inmesi ve kimsenin gece yarısı sunucu odasına gitmesine gerek kalmamasıdır.

Plazada karşılığı nettir. Şehir elektriği kesildiğinde jeneratör devreye girer, ama anında değil: birkaç saniye karanlık olur, bilgisayarınız kapanır, sonra ışıklar yanar. Jeneratör kesintiyi yok etmez, süresini kısaltır. Gerçekten hiç kesinti istemiyorsanız cihazınızın ayrıca kesintisiz güç kaynağına bağlı olması gerekir; sanallaştırma tarafında bunun karşılığı, uygulamanın kendi içinde birden fazla sunucuya yayılmış olmasıdır.

Buradan çıkan planlama kuralı, konsolidasyonun risk yoğunlaştırma sorununu kapatan tek şeydir: kümenin kapasitesi, bir sunucu tamamen kaybedildiğinde kalanların bütün yükü kaldırabileceği şekilde hesaplanır. İki sunuculu bir kümede her iki sunucu da yüzde seksen doluysa, biri düştüğünde diğerinin yüzde yüz altmışlık bir yükü kaldırması beklenir; kaldıramaz. Yüksek erişilebilirlik yapılandırması açıktır, panelde yeşil görünür ve o gün işe yaramaz.

Kapasite Planlama: Kaç Sanal Makine, Ne Kadar Kaynak?

Boyutlandırma, mevcut yükü ölçmekle başlar, tahmin etmekle değil. Yeni bir sanallaştırma altyapısı kurgularken cevaplanması gereken sorular sırayla şunlardır:

1. Bugün gerçekte ne kadar kaynak kullanılıyor? Sunucuların satın alma sırasındaki özellikleri değil, son birkaç aydaki gerçek işlemci, bellek ve disk kullanımı.
2. Tepe yük ne zaman ve ne kadar? Ay sonu, bordro günü, dönem başı gibi zirveler ortalamayı gizler; boyutlandırma ortalamaya değil zirveye bakar.
3. Bir sunucu düştüğünde ne olacak? Kümedeki toplam kapasite, bir sunucu tamamen kaybedildiğinde kalan sunucuların yükü kaldıracağı şekilde planlanır. Buna N+1 denir ve konsolidasyonun risk yoğunlaştırma tarafını dengeleyen tek şeydir.
4. Depolama ne kadar hızlı olmalı? Sanallaştırmada en sık gözden kaçan kalem budur. Alan kolayca hesaplanır; asıl darboğaz, aynı anda onlarca makinenin disk isteğini karşılayacak hızdır.
5. Büyüme payı ne kadar? Kurulduğu gün yüzde doksan dolu bir altyapı, ilk yeni projede yeniden yatırım ister.

Ne Zaman Sanallaştırılmaz?

Her iş yükü sanallaştırılmaz ve bunu söylemek satışı zayıflatmaz, güçlendirir. Sanallaştırma katmanı bir bedel alır: makine ile donanım arasına bir aracı girer ve o aracı kaynak paylaştırdığı için gecikme öngörülemez hale gelir. Çoğu iş yükü bunu fark etmez; bazıları doğrudan buna takılır.

Fiziksel sunucuda kalması gereken durumlar dar ama gerçektir:

• Özel donanıma bağlı iş yükleri. Grafik işlemcisine, ses kartına ya da özel bir yan karta doğrudan erişim gerektiren sistemler. Bu donanımı sanal makineye geçirmek mümkündür ama geçirdiğiniz anda o makine canlı göç edemez, yani sanallaştırmanın en değerli özelliğini kaybedersiniz.
• Çok katı gecikme toleransı olan sistemler. Gerçek zamanlı üretim kontrolü ve benzeri iş yükleri, milisaniyelik dalgalanmayı hata sayar.
• Lisansı donanıma bağlı uygulamalar. Bazı üreticiler lisansı belirli bir fiziksel makineye bağlar; sanal ortamda çalıştırmak teknik olarak mümkün olsa da destek dışı kalabilirsiniz. Bu, teknik değil sözleşme kısıtıdır ve satın alma aşamasında sorulur.

Bunların dışında kalan iş yüklerinin büyük çoğunluğu için doğru cevap sanallaştırmadır. Karar verirken ölçüt “önemli mi” değil, “donanımın kendisine mi bağlı” olmalıdır; kritik olması bir sistemi fiziksel bırakmak için gerekçe değildir, aksine yüksek erişilebilirlikten en çok o yararlanır.

Fiziksel sunucuların sanal ortama aktarılması, kapasite planlamasının hemen ardından gelen ayrı bir iştir ve kendi metodolojisi vardır; taşıma sırası, bağımlılık analizi, kesinti penceresi ve geri alma planı dahil olmak üzere veri merkezi migration ve konsolidasyon rehberimizde ele alıyoruz.

Sonuç: Görünmeyen Kat Planı

Sanallaştırma, bir donanımı çoğaltmak değil, onu bölüştürmenin kurallarını yazmaktır. Bu makalede hypervisor’ın üstündeki işletim sistemine sahte bir donanım sunduğunu gördük, iki hypervisor tipini ayırdık, vCPU’nun bir çekirdek değil sıraya girme hakkı olduğunu ve fazla vCPU vermenin makineyi neden yavaşlattığını konuştuk, konteynerin nerede farklı bir katman olduğunu, snapshot ile yedeğin neden aynı şey olmadığını ve boyutlandırmanın hangi sorularla yapıldığını ele aldık.

Geriye tek bir cümle kalacaksa şu olsun: sanallaştırmada verilen her söz, gerçekte var olan bir kaynağın üzerine yazılır. Otoparkı iki kat fazla satabilirsiniz ve bu çoğu gün sorun çıkarmaz; ama kaç kişiye söz verdiğinizi bilmiyorsanız, kuyruğun oluştuğu sabah sebebini de bulamazsınız.

Sahada gördüğüm sanallaştırma sorunlarının çoğu hypervisor’ın kendisinden çıkmıyor. Kimsenin ölçmediği bir doluluk, kimsenin silmediği bir snapshot, kimsenin hesaplamadığı bir sunucu arızası senaryosu ve fiziksel sunucudan olduğu gibi kopyalanmış özellikler; dördü de kurulum günü değil, aylar sonra fatura kesiyor.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.