Sanallaştırma Kurulumu ve Geçişi: Proxmox, Hyper-V, VMware

Sanallaştırma kurulumu, bir kurumun sunucularını birkaç güçlü fiziksel makinenin üzerinde çalışan sanal sunuculara taşıyan altyapının kurulması, ardından bugün çalışan sistemlerin o altyapıya kesintisi planlanmış biçimde geçirilmesidir. Biz bu işi uçtan uca yapıyoruz: platform seçimi ve boyutlandırma, Proxmox, Hyper-V ya da VMware kurulumu, cluster ve yüksek erişilebilirlik, yedekleme sunucusu, fiziksel ve sanal sunucuların taşınması ve raporlu teslim.

Bu sayfa BT sistem yönetimi hizmetimizin sanallaştırma kolu ve sunucu kurulumu işimizin bir adım ötesi. Hipervizörün sanal sunucuya donanımı nasıl gösterdiğini, overcommit ve kapasite planlamasını hypervisor ve sanallaştırma rehberimizde anlattık; bu sayfa o bilginin sizin altyapınızda karara ve işe dönüştüğü yerdir.

Bir demiryolu hattı yenilenirken seferler durdurulmaz. Yeni ray yan tarafa döşenir, çalışma seferlerin en seyrek olduğu gece saatlerine alınır, yeni hattan önce yolcusuz bir deneme treni geçer. Eski makas yeni hat kendini kanıtlayana kadar sökülmez. Sanallaştırma geçişi de böyle yürür: yolcu, yani kullanıcı, sabah işine geldiğinde trenin gece başka bir raydan geçtiğini fark etmemelidir.

Sanallaştırma Kurulumunda Ne Yapıyoruz, Ne Yapmıyoruz?

Sanallaştırma projesi iki işin toplamıdır: yeni hattı döşemek ve seferleri üzerine almak. Tekliflerde en çok ikinci yarı belirsiz bırakılır, o yüzden ikisini de kalem kalem yazıyoruz.

Yaptıklarımız:

• Envanter ve bağımlılık haritası. Bugün çalışan her sunucunun ne iş yaptığını, kime bağlı olduğunu ve hangi lisansı taşıdığını çıkarıyoruz. Taşınmayacak, emekliye ayrılacak sunucular da bu aşamada belli olur.
• Platform seçimi ve boyutlandırma. Proxmox, Hyper-V ve VMware arasından ortamınıza uyanı seçiyor, kaç host ile ne kadar işlemci, bellek ve disk gerektiğini hesaplıyoruz. Seçimin gerekçesi yazılı olarak onayınıza gelir.
• Hipervizör kurulumu. Host’ları kuruyor, sanal ağları ayırıyor ve yönetim erişimini açıyoruz.
• Cluster ve yüksek erişilebilirlik. İki ya da daha fazla host’u paylaşımlı storage’la birbirine bağlıyoruz; bir host düştüğünde sanal sunucular diğerinde yeniden açılır.
• Yedekleme sunucusu. Sanal sunuculardan ayrı bir donanımda duran yedekleme ünitesini kuruyor ve teslimde en az bir kez geri dönüşü deniyoruz. Proxmox ortamında bu iş için üreticinin kendi Proxmox Backup Server’ı kullanılabilir.
• P2V geçişi. Çalışan fiziksel sunucuları sanal sunucuya dönüştürüyoruz.
• V2V geçişi. Mevcut sanal ortamı başka bir platforma taşıyoruz; bugün bu işin en sık sebebi VMware’den çıkış.
• Lisans. Seçilen platformun lisansını ya da aboneliğini tedarik edebiliyoruz; teklifte ayrı kalem olarak durur.
• Raporlu teslim. Mimariyi, taşıma kayıtlarını ve yönetim erişimlerini yazılı olarak devrediyoruz.

Bu işin bittiği yer:

• Sistem odasının elektrik ve mekanik tesisatı bizim işimiz değil. Kabinet beslemesi ve iklimlendirme hazır olduktan sonra kuruluma giriyoruz; odanın içinin nasıl kurgulandığı sistem odası kurulumu hizmetimizin konusu.
• Yedekleme sunucusunu kuruyoruz, yedekleme düzenini ayrıca yürütüyoruz. Retention policy, uzak kopya ve düzenli geri dönüş testi kurulumla bitmeyen, sürekli bir iş; o düzen veri yedekleme hizmetimizin kapsamında.

Sunucu Sanallaştırma Kime Gerekir?

Sahada gördüğümüz sanallaştırma kararları bir plandan değil, bir olaydan doğuyor. En sık karşılaştığımız tetikleyiciler şunlar:

• VMware yenileme faturası geldi. Broadcom satın almasından sonra kalıcı lisanslar kalktı, model aboneliğe döndü ve paketler birleşti. Birçok kurum ilk kez “Bu platformda kalmalı mıyız?” sorusunu hesapla soruyor.
• Fiziksel sunucuların ömrü doldu. Beş ayrı kutunun garantisi farklı tarihlerde bitiyor, her biri ayrı disk, ayrı güç ve ayrı yedek istiyor.
• Bir sunucu durduğunda iş duruyor. Kesintiye tahammül azaldı ama mimari hâlâ her rolü tek bir makineye bağlıyor.
• Sistem odası sıkıştı. Yer, soğutma ve enerji tüketimi, sunucu sayısıyla birlikte büyüyor.

Alt sınırı da açıkça çizelim. On kullanıcı, tek uygulama ve tek rolün olduğu bir ofiste hipervizör katmanı bir fatura kalemi ve bir öğrenme yükü ekler, karşılığında pek bir şey vermez. Neyin sanallaştırılmaması gerektiğini rehberde ayrıca yazdık.

Proxmox, Hyper-V, VMware: Sizin Durumunuzda Hangisi?

Ana hizmet sayfamız üç platformu karşılaştırıyor. Burada karşılaştırma yapmıyoruz; hangi durumda hangisini önerdiğimizi söylüyoruz. Üçünü de kuruyoruz ve kararı platform değil, sizin lisans stoğunuz ile ekibiniz verir.

• Hyper-V, ortam Windows ağırlıklıysa ve Windows Server lisansı zaten elinizdeyse mantıklıdır. Datacenter sürümü sınırsız sanal Windows sunucu hakkı verir, Standard sürümü tam lisanslanmış her host için iki sanal sunucu hakkı taşır. Lisans modelinin ayrıntısı Windows Server yazımızda duruyor.
• Proxmox VE, yazılım maliyetini sıfırlamak istiyorsanız ve içeride Linux yetkinliği ya da sözleşmeli bir destek varsa doğru seçimdir. Kurumsal paket deposu ve üretici desteği işlemci soketi başına aboneliktir, isteğe bağlıdır. Sürüm 8.2’den beri ESXi ortamından sanal sunucu içe aktarma aracı platformun kendisinde geliyor.
• VMware, mevcut ortam zaten VMware’deyse, ekip bu platformda yetkinse ve yenileme bedeli bütçeye sığıyorsa hâlâ mantıklı bir seçimdir. Taşımanın da bir maliyeti ve riski var; hesap kalmayı gösteriyorsa kalmayı öneriyoruz.

Tek Host mu, Cluster mı?

Tek hatlı bir demiryolunda raydaki tek arıza bütün seferleri durdurur. Tek host’lu sanallaştırma da böyledir: beş sunucuyu tek makineye topladığınızda, o makinenin arızası beş sunucunun birden durması demektir. Bu, kurumun fark etmediği tek nokta arızasının en pahalı biçimlerinden biri.

Cluster bu riski dağıtır, ama iki şeyi bilerek kurmak gerekir.

1. Yüksek erişilebilirlik kesintisizlik değildir. Host düştüğünde üzerindeki sanal sunucular diğer host’ta yeniden başlar; kullanıcı birkaç dakikalık bir kopma yaşar. Sıfır kesinti isteyen uygulama bunu kendi katmanında çözer.
2. İki host’lu cluster üçüncü bir oy ister. İki host arasındaki bağlantı koptuğunda ikisi de diğerinin öldüğünü sanıp aynı sanal sunucuyu açmaya kalkabilir; aynı diske iki taraftan yazılması veriyi bozar. Buna karşı çoğunluk kuralı işler: Proxmox’ta üçüncü bir host ya da hafif bir tanık cihaz, Hyper-V’de bir tanık disk ya da paylaşım bu oyu verir.

Kesinti tahammülünüz düşük değilse cluster’a para vermek zorunda değilsiniz. İlk görüşmede tek soruyla karar veriyoruz: bu sistemler yarım gün durursa ne olur?

Sanallaştırma Geçişinde Sanal Sunucuyu Ne Bozar?

Platformu seçip hattı döşemek işin öngörülebilir kısmı. Asıl risk, bugün çalışan sunucuları o hatta almakta.

Türkiye’de demiryolu ray açıklığı 1435 milimetre, Kafkasya ve Orta Asya’da 1520 milimetre. Bakü-Tiflis-Kars hattında bu yüzden Ahılkelek’te bir boji değişim istasyonu var: vagonlar yüklerini indirmeden altlarındaki tekerlek takımı değiştirilerek öbür raya geçiyor. Sanallaştırma geçişi tam olarak budur. Sunucunun yükü, yani işletim sistemi, uygulamaları ve verisi, olduğu gibi kalır. Değişen şey bojidir: sunucunun gördüğü sanal donanım.

Geçişte bozulan şeyler de hep o bojide çıkar:

• Disk formatı. VMware’in VMDK diski Proxmox’ta QCOW2 ya da RAW, Hyper-V’de VHDX biçimine dönüştürülür.
• Disk denetleyicisi sürücüsü. Windows sunucu yeni platformun disk denetleyicisi için sürücüyü taşımıyorsa açılışta kendi diskini bulamaz ve mavi ekranla durur. Sürücü taşımadan önce yüklenir.
• Ağ kartı. Yeni sanal ağ kartı yeni bir donanım sayılır; eski karta yazılmış sabit IP ayarı ona geçmez ve sunucu açılır ama ağa çıkmaz. MAC adresine bağlı DHCP rezervasyonları da bu anda kopar.
• Donanıma bağlı lisanslar. Bazı uygulamalar lisansını makinenin donanım kimliğine bağlar ve yeni kimliği başka bir makine sayar.

Benzetmenin koptuğu yer de burası. İstasyondaki vagon tekerleğinin değiştiğini bilmez; sanal sunucu ise değişimi açılışta fark eder ve yeni donanımın sürücüsü o andan önce hazır değilse raydan çıkar. Bu yüzden her geçişte asıl iş dönüştürme aracına basmak değil, bu dört kalemin sunucu sunucu önceden hazırlanmasıdır.

P2V geçişinde bunlara bir kalem daha eklenir. Fiziksel makinenin RAID, yönetim ajanı ve donanım sürücüleri sanal ortamda anlamsızdır ve taşımadan sonra temizlenir. Taşımadan önce sorulacak soru ise teknik değil: bu sunucu olduğu gibi taşınmalı mı, rolü yeni bir sanal sunucuya temiz mi kurulmalı, yoksa üzerindeki uygulama zaten emekliye mi ayrılmalı? Bu kararın disiplinini veri merkezi migration rehberimizde yazdık.

Sanallaştırma Kurulumu ve Geçişini Nasıl Yapıyoruz?

Sıra, riskin en ucuz olduğu yerden en pahalı olduğu yere doğru ilerler.

1. Uzaktan ön görüşme, ücretsiz. Kaç sunucunuz olduğunu, hangi platformu kullandığınızı, lisanslarınızın ne zaman bittiğini ve kesintiye ne kadar tahammül edebildiğinizi konuşuyoruz. Görüşmenin sonunda işin mertebesini söylüyoruz.
2. Envanter ve bağımlılık haritası. Her sunucunun rolü, bağlı olduğu sistemler ve yukarıdaki dört kalemdeki durumu çıkarılır.
3. Tasarım. Platformu, host sayısını, storage modelini, yedekleme ünitesini ve sanal ağ düzenini belirliyoruz. Yönetim, storage ve canlı göç trafiği ayrı VLAN’lara alınır. Tasarım onaylanmadan kurulum başlamaz.
4. Yeni hattın döşenmesi. Host’lar, cluster, storage ve yedekleme sunucusu eski ortamın yanında, ona dokunmadan kurulur. Hipervizörü SD karta ya da USB belleğe değil dayanıklı bir yerel diske kuruyoruz.
5. Deneme treni. Önce kritik olmayan bir sanal sunucu taşınır, açılır, ağa çıktığı ve uygulamasının cevap verdiği görülür; yedeği alınıp geri döndürülür. Bu adım geçilmeden asıl taşımaya başlanmaz.
6. Gruplar hâlinde taşıma. Sunucuları tek gecede değil, birkaç gruba bölerek taşıyoruz. Her grup mesai dışındaki ayrı bir pencerede taşınır ve kendi doğrulamasıyla kapanır; kritik sistemler en son gruba kalır.
7. Paralel dönem ve söküm. Eski ortam kapatılır ama belirlenen süre boyunca silinmez; geri dönüş yolu o süre açık kalır. Söküm yeni hat kendini kanıtladıktan sonra yapılır.
8. Raporlu teslim. Teslim dosyası yazılı olarak elinize geçer.

Teslim dosyasının içinde şunlar var:

• Mimari şema. Host’ları, storage’ı, sanal ağları ve aralarındaki bağlantıları gösterir.
• Host envanteri. Her host’un donanımını, hipervizör sürümünü ve cluster üyeliğini kaydeder.
• Sanal sunucu listesi. Her sunucuya ayrılan kaynağı, sunucunun bulunduğu host’u ve taşındığı tarihi gösterir.
• Taşıma kayıtları. Her taşıma grubunda yapılan doğrulamanın sonucunu ve çıkan sorunları yazar.
• Yedekleme planı ve geri dönüş denemesinin sonucu. Neyin ne sıklıkla yedeklendiğini ve teslimdeki denemenin çıktısını içerir.
• Yönetim erişimleri. Hangi hesabın hangi yetkiyle durduğunu listeler.
• Bilerek yapmadığımız işlerin listesi. Taşıma sırasında gördüğümüz ama kapsam dışında kalan eksikleri bu listeyle size bırakırız.

Sahada Ne Yaptık?

Yukarıdaki iki tasarım kararı, yani sunucu ile storage’ın ayrı tutulması ve hipervizörün dayanıklı bir diske kurulması, bir taşıma gecesinden geliyor.

Veri merkezi taşıma vakasında VMware ortamı, sunucusu, storage’ı ve switch’iyle birlikte bir gece penceresinde başka bir veri merkezine taşındı. Taşıma sırasında hipervizör bozuldu; muhtemel sebebi, yıllar önce sunucunun dahili SD kartına kurulmuş olmasıydı. Sınırlı yazma ömrü olan bu kartlar en çok bir kapatıp açma döngüsünde bozulur. Veri kaybı olmadı, çünkü sanal sunucular host’un kendi diskinde değil ayrı bir storage ünitesinde duruyordu; hipervizör yeniden kuruldu, storage’a bağlandı ve iş planlanan dört saatlik pencerede bitti.

Veeam yedekleme vakasında ise VMware altyapısının tamamı test edilmiş bir yedeğe alındı. Bu sayfanın yedekleme sunucusunu ayrı donanımda kurup teslimde geri dönüşü denemesinin sebebi orada görünüyor.

Sanallaştırma Kurulumu Fiyatını Ne Belirler?

Bedeli belirleyen şey sunucu sayısından çok mimaridir. Teklifleri karşılaştırırken bakacağınız kalemler şunlar:

• Host sayısı ve aralarındaki kurgu. Tek host, iki host ve tanık, ya da üç ve daha fazla host’lu cluster aynı iş değil.
• Storage modeli. Host’ların kendi diskleriyle, ayrı bir paylaşımlı storage ünitesiyle ya da host’lara yayılan yazılım tanımlı storage’la kurulan yapılar farklı emek ister.
• Yedekleme ünitesi. Ayrı bir yedekleme sunucusu kurulacaksa teklifte kendi kalemiyle görünür.
• Taşınacak sunucu sayısı ve türü. V2V geçişi ile P2V geçişi aynı emeği istemez; donanıma bağlı lisansı olan ya da belgesiz sunucular ayrıca hazırlık ister.
• Sıfırdan kurulum mu, mevcut ortamın yenilenmesi mi? Çalışan bir ortamı taşımak, boş bir sahaya kurmaktan uzun sürer.
• Lisans. Teklifte ayrı satırda durur. Hyper-V, Windows Server lisansınızın içinde gelir; Proxmox’un aboneliği isteğe bağlıdır; VMware ise abonelik bedeli ister.
• Kesinti pencereleri. Sunucular kaç ayrı gecede ya da hafta sonunda taşınıyorsa, yani mesai dışı çalışma kaç pencereye yayılıyorsa, bedel de o ölçüde artar.

Teklif toplarken tek bir soru çoğu şeyi ayırır: teklifte deneme sunucusu ve eski ortamın ne zaman söküleceği yazılı mı? İkisi de yoksa o teklif treni yeni rayın üzerine koyuyor ama eski makası çoktan sökmüş demektir.

Sonuç: Yeni Hattan İlk Sefer

İyi yapılmış bir sanallaştırma geçişinin tek görünür belirtisi, görünmemesidir. Kullanıcı pazartesi sabahı aynı uygulamayı aynı adla açar; değişen tek şey, bir sunucu arızalandığında bunun artık bir iş günü değil birkaç dakika sürmesidir.

Hat açıldıktan sonra bakım takvimi başlar. Host yamaları, kapasite takibi ve yedek kontrolünü kendi ekibiniz teslim dosyasıyla sürdürebilir; bize bırakmak isterseniz kurumsal bakım anlaşmasıyla kurulumu yapan ekip işletmeye de devam eder.

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ürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn