Platform kararını verdiniz: VMware’den çıkıp Hyper-V ya da Proxmox VE’ye geçeceksiniz. Şimdi asıl soru şu: Muhasebe veritabanını, dosya sunucusunu ve etki alanı denetleyicisini kesintiyi en aza indirerek, gerektiğinde geri dönebileceğiniz şekilde nasıl taşırsınız? Bu yazı, platform seçimini değil, seçimden sonraki uygulama planını anlatır. Hangi platformun size uyduğunu henüz tartıyorsanız önce VMware, Hyper-V ve Proxmox karşılaştırması yazımıza, lisans tarafındaki değişiklikler için Broadcom sonrası VMware lisanslaması yazımıza göz atabilirsiniz.
1. Envanter: neyi taşıdığınızı bilin
Geçiş planı bir listeyle başlar. vCenter’dan dışa aktarılan bir tablo iyi bir başlangıçtır, ama yeterli değildir. Her sanal makine için şu bilgileri toplayın:
- İşletim sistemi ve sürümü, önyükleme tipi (BIOS ya da UEFI), Secure Boot ve sanal TPM kullanımı.
- Disk sayısı ve boyutu, disklerin hangi datastore üzerinde durduğu, vSAN ya da şifreli disk kullanılıp kullanılmadığı.
- Ağ kartları, VLAN’lar, sabit IP adresleri ve DHCP rezervasyonları.
- Açık kalmış anlık görüntüler (snapshot).
- Uygulama bağımlılıkları: ERP sunucusunun hangi veritabanına, hangi lisans sunucusuna bağlandığı.
- İş sahibi, kabul edilebilir kesinti süresi ve uygun bakım penceresi.
Son madde teknik değildir ama planın geri kalanını belirler. Hangi sistemin ne kadar durabileceğini RTO ve RPO hedefleriyle netleştirmek, taşıma sırasını da ortaya çıkarır.
2. Uyumluluk ve hedef ortamın hazırlığı
Envanter tamamlandığında her sanal makineyi hedef platform açısından kontrol edin. Uygulama üreticisi Hyper-V ya da KVM tabanlı ortamı destekliyor mu? Donanıma bağlı bir lisans, sanal ağ kartının MAC adresi değişince yeniden etkinleştirme istiyor mu? Eski bir işletim sistemi hedef platformun sürücüleriyle çalışıyor mu?
Hedef tarafta da hazırlık gerekir: küme kurulumu, depolama, sanal ağlar ve VLAN eşlemesi, zaman senkronizasyonu, izleme ve yedekleme ajanları. Hedef ortamı taşımadan önce boş hâliyle test etmek, geçiş gecesinde altyapı sorunu çıkma ihtimalini azaltır. Platformlara özel ayrıntılar için Hyper-V ve Proxmox VE sayfalarımıza bakabilirsiniz.
3. Yedek: geçişin sigortası
Hiçbir sanal makine, doğrulanmış güncel bir yedeği olmadan taşınmamalıdır. Yedeğin alınmış olması yetmez; geri yüklenebildiği test edilmiş olmalıdır. Dönüşüm aracı yarıda kalırsa ya da hedefte bir disk bozuk açılırsa dönülecek yer bu yedektir.
Platformdan bağımsız bir yedekleme yazılımı burada ikinci bir işlev de görür. Veeam Backup & Replication’ın resmi belgelerine göre VMware yedeklerinden iş yükleri Hyper-V ya da Proxmox VE sanal makinesi olarak geri yüklenebilir; Veeam bu yöntemi platformlar arası geçiş senaryoları için de önerir. Bu sayede yedek, aynı zamanda bir taşıma yoluna dönüşür. Ayrıntılar için Veeam ve genel çerçeve için yedekleme sayfalarımıza göz atabilirsiniz.
4. Dönüşüm araçları: resmi yollar
Sanal makineyi bir platformdan diğerine taşımanın birkaç yolu vardır. Aşağıdakiler, üreticilerin kendi belgelerinde anlattığı yöntemlerdir.
Proxmox VE: ESXi içe aktarma sihirbazı
Proxmox VE 8 ile birlikte gelen içe aktarma sihirbazında ESXi sunucusu bir depolama kaynağı olarak eklenir; sanal makineler listeden seçilip içe aktarılır. Proxmox belgelerine göre ESXi 6.5 ile 8.0 arası sürümler desteklenir ve kesintiyi azaltmak için sanal makineyi içe aktarma sürerken başlatan canlı içe aktarma seçeneği vardır. Kaynak sanal makine yine de kapatılmalıdır. Belgelenen kısıtlar önemlidir: vSAN üzerindeki diskler ve depolama politikasıyla şifrelenmiş diskler içe aktarılamaz, anlık görüntüler işlemi ciddi ölçüde yavaşlatır.
Alternatif olarak OVF dışa aktarımı ya da VMDK disklerinin komut satırından içe aktarılması da desteklenir. Windows sanal makinelerde önyükleme diskini VirtIO SCSI sürücüsüne geçirmek için ek adımlar gerekir; VMware Tools’un önceden kaldırılması ve ağ ayarlarının not edilmesi önerilir.
Hyper-V: Windows Admin Center ve VMM
Microsoft’un Windows Admin Center için geliştirdiği VM Conversion uzantısı, vCenter 6.x, 7.x ve 8.x’teki sanal makineleri Hyper-V’ye taşır. Önce kaynak makine çalışırken tam kopya alınır, sonra değişen bloklar aktarılır; son aşamada kaynak kapatılıp kalan fark senkronize edilir. Uzantı bir seferde en fazla 10 sanal makineyi gruplayabilir, sabit IP ayarlarını korur ve Windows makinelerde VMware Tools’u taşıma sonrasında kaldırır. Linux makinelerde Hyper-V sürücülerinin taşımadan önce yüklenmesi gerekir. Yazının hazırlandığı tarihte uzantı önizleme (preview) aşamasındadır; üretimde kullanmadan önce güncel durumunu kontrol edin.
System Center Virtual Machine Manager (VMM) kullanıyorsanız dönüştürme sihirbazı da bir seçenektir. Microsoft belgelerine göre VMM’de çevrim çevrimdışı yapılır: Kaynak makine kapatılmalı ve VMware Tools kaldırılmış olmalıdır; IDE veri yoluna bağlı diski olan makineler dönüştürülemez. Eski rehberlerde geçen Microsoft Virtual Machine Converter (MVMC) aracının desteği 2017’de sona ermiştir.
Hangisi ne zaman?
| Yöntem | Kesinti | Ne zaman uygun? |
|---|---|---|
| Proxmox içe aktarma sihirbazı | Kaynak kapatılır; canlı içe aktarma ile kısalır | ESXi’den Proxmox VE’ye doğrudan taşıma |
| Windows Admin Center VM Conversion | Son senkronizasyon süresince | vCenter’dan Hyper-V’ye, kesinti penceresi dar sistemler |
| VMM dönüştürme sihirbazı | Çevrim süresince, çevrimdışı | VMM kullanan Hyper-V ortamları |
| Yedekten platformlar arası geri yükleme | Son yedekten sonraki değişikliklere bağlı | Zaten Veeam kullanan, yedeği test etmek isteyen ortamlar |
5. Pilot ve taşıma dalgaları
İlk taşımayı kritik olmayan, ama gerçek bir iş yükü taşıyan bir sistemle yapın: bir test sunucusu, bir yazdırma sunucusu ya da bir iç uygulama. Pilotta yalnızca makinenin açılmasına değil, şu sorulara bakın:
- Uygulama, disk ve ağ performansı öncekiyle karşılaştırılabilir mi?
- Yedekleme görevi yeni platformda çalışıyor, geri yükleme testi başarılı mı?
- İzleme araçları yeni sunucuyu ve sanal makineyi görüyor mu?
- Dönüşüm ne kadar sürdü? Bu süre, büyük sunucular için bakım penceresini hesaplamanıza yarar.
Pilot sonrasında sanal makineleri bağımlılıklarına göre dalgalara ayırın. Birbirine sıkı bağlı sistemleri (uygulama sunucusu ve veritabanı gibi) aynı dalgada taşıyın. Etki alanı denetleyicisi gibi rolleri çoğu zaman dönüştürmek yerine hedefte yeni bir sunucu kurup rolü devretmek daha temiz bir yoldur.
6. Geri dönüş planı
Her taşıma adımının yazılı bir geri dönüş yolu olmalıdır. En basit ve en güvenilir kural şudur: Kaynak sanal makineyi hemen silmeyin. Taşıma sonrasında kapalı ve adı değiştirilmiş hâlde bekletin; yeni makine belirli bir süre sorunsuz çalıştıktan sonra kaldırın.
- Karar noktası: Hangi test başarısız olursa geri dönüleceğini ve kararı kimin vereceğini önceden yazın.
- Veri farkı: Yeni makinede birkaç saat iş yapıldıysa geri dönüşte bu verinin ne olacağını planlayın.
- DNS ve IP: Eski ve yeni makinenin aynı anda ağda açık kalmaması için sıralamayı belirleyin.
- Lisans takvimi: VMware aboneliğinizin bitiş tarihini, geri dönüş ihtimalini de kapsayacak şekilde değerlendirin.
Kapanış aşamasında eski ortamdaki yedek görevlerini, izleme kayıtlarını ve lisansları temizleyin, belgeleri güncelleyin.
Unna ile planlı geçiş
Geçişin zorluğu araçta değil, hazırlıkta ve sıralamadadır. Bu yüzden işe ölçümle başlarız.
- Önce dinleriz. Mevcut VMware ortamınızın envanterini ve gerçek kaynak kullanımını çıkarır, hangi sistemin ne kadar durabileceğini sizinle birlikte belirleriz.
- Birlikte planlarız. Hedef platformu, taşıma dalgalarını, bakım pencerelerini ve her adımın geri dönüş yolunu yazılı bir plana dökeriz.
- Kurar ve taşırız. Hedef kümeyi kurar, pilotla başlar, her taşımadan önce yedeği doğrular, sonrasında uygulamaları kullanıcılarınızla test ederiz.
- Yanınızda kalırız. Yeni platformda güncellemeleri, kapasiteyi ve yedekleme görevlerini izlemeye devam ederiz.
Genel çerçeve için sanallaştırma sayfamıza bakabilir, geçiş takviminizi konuşmak için bize yazabilirsiniz.
