Proxmox'ta Canlı Göç (Live Migration)

Bir hipervizöre bellek takmanız, çekirdeği güncellemeniz ya da arızalı bir disk denetleyicisini değiştirmeniz gerekiyor — ama üzerinde çalışan on beş sanal makine var ve hiçbirinin kesintiye uğramaması gerekiyor. Proxmox canlı göç tam olarak bu senaryo için vardır: çalışan bir sanal makineyi, kapatmadan, kullanıcıları bile fark etmeden başka bir düğüme taşır. İyi yapılandırılmış bir kümede bu işlem birkaç saniye içinde ve tek bir ping paketi bile kaybetmeden tamamlanır.

Ama "iyi yapılandırılmış" ifadesi burada gerçek bir şart listesi taşıyor. Yanlış CPU tipi seçtiyseniz göç sırasında misafir çöker; göç trafiğini corosync ile aynı hatta koyduysanız kümeyi düşürürsünüz; yerel diskle çalışıyorsanız göç saatler sürebilir. Bu rehberde canlı göçün gerçekte nasıl çalıştığını, ön koşulları, CPU uyum meselesini, göç ağını ayırmayı, yerel diskli göç seçeneklerini ve karşılaşacağınız hataların çözümünü anlatacağım. Kümeniz yoksa önce Proxmox cluster kurulumu yazısındaki adımları tamamlayın.

Canlı Göç Perde Arkasında Nasıl Çalışır#

Canlı göç, sanal makinenin belleğini çalışırken hedef düğüme kopyalama sanatıdır. Süreç kabaca dört aşamada ilerler.

Önce hazırlık: hedef düğümde aynı yapılandırmaya sahip boş bir QEMU süreci başlatılır, ağ arayüzleri ve disk bağlantıları hazırlanır. Sonra ilk bellek turu: kaynak düğüm, misafirin belleğinin tamamını hedefe gönderir. Bu sırada misafir çalışmaya devam ettiği için gönderdiğiniz sayfaların bir kısmı gönderildikten sonra değişir — bunlara "kirli sayfa" (dirty page) denir.

Üçüncü aşama yinelemeli turlar: yalnızca kirlenen sayfalar tekrar gönderilir. Her turda gönderilecek veri azalır, çünkü kalan süre kısaldıkça daha az sayfa kirlenir. Son aşama ise geçiş anı (cutover): kalan kirli sayfa miktarı yeterince küçüldüğünde misafir kaynakta bir anlığına duraklatılır, son sayfalar ve CPU durumu gönderilir, hedefte çalıştırılır ve ağ trafiği yeni düğüme yönlendirilir. Bu duraklama tipik olarak milisaniyeler mertebesindedir.

Bu mekanizmanın en önemli sonucu şudur: misafir belleği ne kadar hızlı kirletiyorsa, göç o kadar zorlaşır. Yoğun bir veritabanı sunucusu saniyede gigabaytlarca sayfayı değiştiriyorsa ve ağınız bunu taşıyamıyorsa, yinelemeli turlar hiçbir zaman yakınsamaz. QEMU bu durumda "auto-converge" ile misafirin CPU'sunu kısarak bellek kirletme hızını düşürür; yani göç tamamlanır ama misafir kısa süre yavaşlar. Bu yüzden ağ hızı, canlı göçün başarısında bellek boyutundan bile önemlidir.

Ön Koşullar ve CPU Uyum Meselesi#

Canlı göç için sağlanması gereken şartlar sıralı bir kontrol listesi hâlinde şöyledir:

1. Düğümler aynı kümede olmalı. Küme dışı iki Proxmox arasında canlı göç yapılamaz.
2. Paylaşımlı depolama olmalı (Ceph, NFS, iSCSI) ya da yerel disk göçünü açıkça talep etmelisiniz.
3. Köprü isimleri tüm düğümlerde aynı olmalı. Hedefte vmbr0 yoksa göç başarısız olur.
4. CPU üreticisi aynı olmalı. Intel'den AMD'ye ya da tersine canlı göç yapılamaz.
5. CPU tipi uyumlu seçilmiş olmalı. Bu, listedeki en çok atlanan maddedir.

Beşinci maddeyi açalım, çünkü üretimde en sık burada tökezlenir. Bir sanal makinenin CPU tipini host olarak ayarlarsanız, misafir fiziksel işlemcinin tüm komut kümesini görür — en yüksek performans budur. Ama misafirin çekirdeği açılışta bu komut kümesini keşfeder ve kullanır. Daha eski nesil bir işlemciye sahip düğüme göç ettiğinizde, misafir olmayan bir komutu çalıştırmaya kalkar ve çöker. Bu çökme göç anında değil, bazen dakikalar sonra gerçekleşir; sebebini bulmak zordur.

Çözüm, kümedeki en eski işlemcinin desteklediği ortak bir CPU modelini seçmektir. Proxmox bunun için x86-64-v2-AES, x86-64-v3 gibi nesil tabanlı modeller sunar:

# Düğümlerin işlemci modellerini karşılaştır
lscpu | grep -E 'Model name|Flags' | head -2

# VM'in CPU tipini kümede ortak bir modele ayarla
qm set 101 --cpu x86-64-v2-AES

# NUMA'yı açmak büyük VM'lerde bellek yerelliğini iyileştirir
qm set 101 --numa 1

# Mevcut ayarı gör
qm config 101 | grep -E '^cpu|^numa'

CPU tipi seçiminin sonuçlarını tablo hâlinde özetleyeyim:

Genel öneri şudur: kümenizde göç yapacaksanız host kullanmayın. Kaybettiğiniz performans, çoğu iş yükünde ölçülemeyecek kadar küçüktür; kazandığınız ise sunucu bakımını kesintisiz yapabilme özgürlüğüdür.

Göç Ağını Ayırmak#

Varsayılan olarak göç trafiği yönetim ağından geçer. Bu, laboratuvar dışında kabul edilemez bir yapılandırmadır: 32 GB belleğe sahip bir sanal makineyi taşırken hat tamamen dolar, aynı hattan geçen corosync paketleri gecikir, düğümler quorum kaybeder ve HA yapılandırdıysanız sunucular kendini yeniden başlatır. Yani rutin bir bakım işlemi, kümenin tamamını çökerten bir olaya dönüşür.

Göç ağını ayırmak /etc/pve/datacenter.cfg dosyasında tek bir satırla yapılır ve küme genelinde uygulanır:

# /etc/pve/datacenter.cfg
# Göç trafiği ayrı bir ağdan, şifrelemesiz (hızlı) geçsin
migration: type=insecure,network=10.10.30.0/24

# Aynı dosyada faydalı diğer ayarlar
keyboard: tr
console: html5
mac_prefix: BC:24:11

type=insecure ifadesi doğru anlaşılmalı. Varsayılan secure modu göç trafiğini SSH tüneli üzerinden geçirir; bu şifreleme, yüksek hızlı ağlarda tek çekirdekli bir darboğaz yaratır ve 10 GbE hattı doldurmanızı engeller. insecure modu şifrelemeyi kaldırıp doğrudan TCP kullanır. Bu ayarı yalnızca göç ağı fiziksel olarak izole ve güvenilir ise kullanın — kendi anahtarınızdaki özel bir VLAN'da sorun yoktur, internet üzerinden geçen bir bağlantıda asla kullanılmamalıdır.

Ağ tarafını hiç ayırmadıysanız, bond ve VLAN kurulumunu Proxmox ağ yapılandırması: bridge ve VLAN yazısında adım adım anlattım. Göç için ayrılacak hattın kullandığı TCP portları da güvenlik duvarında açık olmalıdır:

Göç Komutları ve Toplu Bakım#

Web arayüzünde göç, sanal makineye sağ tıklayıp Migrate demekten ibarettir. Komut satırı ise otomasyon ve toplu işler için çok daha kullanışlıdır:

# Çalışan bir VM'i canlı olarak taşı
qm migrate 101 pve2 --online

# Yerel diskli bir VM'i taşı (disk de kopyalanır, uzun sürer)
qm migrate 101 pve2 --online --with-local-disks

# Göç bant genişliğini sınırla (MB/s) — üretimi boğmamak için
qm migrate 101 pve2 --online --bwlimit 300

# Hedefte farklı bir depolamaya yerleştir
qm migrate 101 pve2 --online --targetstorage ceph-vm

# LXC konteynerleri: canlı göç YOKTUR, yeniden başlatmalı göç yapılır
pct migrate 200 pve2 --restart

LXC satırı önemli bir farkı gösterir. Konteynerler konak çekirdeği paylaştığı için bellek durumları taşınamaz; Proxmox bu yüzden konteyneri hedefte yeniden başlatır. --restart bayrağı olmadan çalışan bir konteyner göç edilmez. Kesintisiz taşıma gereken iş yüklerini bu yüzden konteyner yerine sanal makinede çalıştırmak daha uygundur.

Bir düğümü bakıma alacaksanız üzerindeki tüm misafirleri tek komutla boşaltabilirsiniz:

# Düğümdeki tüm VM ve konteynerleri diğer düğümlere dağıt
ha-manager crm-command node-maintenance enable pve1

# HA kullanmıyorsanız toplu boşaltma
pvenode migrateall pve2 --maxworkers 2

# Bakım bitince düğümü geri al
ha-manager crm-command node-maintenance disable pve1

--maxworkers 2 değeri aynı anda kaç göçün paralel çalışacağını belirler. Bunu ağ kapasitenize göre ayarlayın; çok yüksek bir değer hattı doyurur ve tüm göçlerin yakınsamasını zorlaştırır.

Bakım rutini için önerdiğim sıra şudur:

1. Bakıma alınacak düğümü belirleyin ve kalan düğümlerin kapasitesini kontrol edin.
2. Göç ağının ayrı olduğunu ve datacenter.cfg ayarının yerinde olduğunu doğrulayın.
3. Kritik sanal makineleri önce taşıyıp doğrulayın, sonra gerisini toplu boşaltın.
4. Düğümde hiç misafir kalmadığını qm list ve pct list ile teyit edin.
5. Bakımı yapın, düğümü geri alın ve isterseniz misafirleri geri taşıyın.

Yerel Disk ve Paylaşımlı Depolama Farkı#

Canlı göçün hızı, esas olarak diskin nerede durduğuna bağlıdır.

Paylaşımlı depolamada (Ceph, NFS, iSCSI) disk zaten her düğümden erişilebilir olduğu için hiç kopyalanmaz; yalnızca bellek taşınır. Bu yüzden göç saniyeler sürer ve büyük bellekli makinelerde bile öngörülebilirdir. Ceph kurulumunu Proxmox'ta Ceph ile dağıtık depolama yazısında ele aldım.

Yerel depolamada (yerel ZFS, LVM-thin) disk hedefe kopyalanmak zorundadır. 500 GB'lık bir disk, 10 GbE hat üzerinde en iyi ihtimalle birkaç dakika sürer; 1 GbE üzerinde saatlere çıkar. Bu göç yine de "canlı"dır — makine çalışmaya devam eder — ama süresi tamamen farklı bir ölçektedir. ZFS depolama tarafını Proxmox'ta ZFS depolama yapılandırması yazısında anlattım.

Tablodaki son sütun kritiktir: yüksek erişilebilirlik yalnızca paylaşımlı depolamayla çalışır. Bir düğüm çöktüğünde yerel diskindeki veriye erişemezsiniz, dolayısıyla HA o makineyi başka bir düğümde açamaz. Yerel diskli göç, planlı bakım için değerli bir araçtır ama HA'nın yerine geçmez. HA kurulumunu Proxmox HA kurulumu yazısında ayrıntılı ele alıyorum.

Sık Karşılaşılan Hatalar ve Çözümleri#

"can't migrate VM with local resources". VM'e düğüme özgü bir kaynak bağlanmıştır: bir ISO dosyası yerel depolamadan takılıdır, bir USB cihazı ya da PCI passthrough cihazı tanımlıdır. Çözüm, ISO'yu çıkarmak (qm set 101 --ide2 none) ve passthrough cihazlarını göç öncesinde kaldırmaktır. Passthrough kullanan makineler doğası gereği canlı göç edilemez, çünkü fiziksel cihaz hedef düğümde yoktur.

"storage 'X' is not available on node 'Y'". Depolama tanımı hedef düğümde yok ya da nodes alanıyla sınırlandırılmış. /etc/pve/storage.cfg dosyasındaki nodes satırını kontrol edin; paylaşımlı depolamada bu satır hiç olmamalıdır.

"bridge 'vmbr1' does not exist on node". Hedef düğümde aynı isimde köprü yok. Küme genelinde köprü isimlerini standartlaştırın; bu, göçün sessizce çalışmasının en basit ön koşuludur.

Göç başlıyor ama bitmiyor, yüzde 99'da takılıyor. Misafir belleği ağdan daha hızlı kirletiyor demektir. Ağ hızını artırın, --bwlimit ile başka trafiği kısın ya da geçici olarak misafirin yükünü azaltın. Son çare olarak makineyi kısa süreliğine duraklatıp taşıyabilirsiniz.

Göçten sonra misafir çöktü ya da yeniden başladı. Neredeyse her zaman CPU tipi uyumsuzluğudur. host kullanıyorsanız kümede ortak bir modele geçin ve misafiri bir kez yeniden başlatın (CPU tipi değişikliği çalışırken uygulanmaz).

Göç çok yavaş, ağ boş görünüyor. type=secure modunda SSH şifrelemesi tek çekirdekte darboğaz yapıyor olabilir. Göç ağı izole ise type=insecure moduna geçin ve farkı ölçün.

Göç sırasında neler olduğunu izlemek için:

# Göç görevlerinin canlı listesi
pvesh get /nodes/pve1/tasks --limit 5

# Ayrıntılı log
journalctl -u pvedaemon -f | grep -i migrat

# Göç sırasında ağ kullanımını izle
iftop -i eno2

Sıkça Sorulan Sorular#

Canlı göç sırasında sanal makine kapanır mı#

Hayır, misafir çalışmaya devam eder. Geçiş anında yalnızca milisaniyeler mertebesinde bir duraklama olur ve bu süre kullanıcılar tarafından fark edilmez; genellikle tek bir ping paketi bile kaybolmaz. Duraklamanın uzaması, misafirin belleği ağ kapasitesinden hızlı kirletmesi durumunda görülür ve bu da genellikle ağın yetersiz olduğunun işaretidir.

Farklı işlemcilere sahip düğümler arasında göç yapabilir miyim#

Aynı üreticiden olduğu sürece (hepsi Intel ya da hepsi AMD) evet, ancak sanal makinenin CPU tipini kümedeki en eski işlemcinin desteklediği ortak bir modele ayarlamanız gerekir. host tipi kullanırsanız misafir fiziksel işlemcinin tüm özelliklerini görür ve daha eski bir düğüme taşındığında çöker. Intel ile AMD arasında canlı göç mümkün değildir.

Canlı göç ne kadar sürer#

Paylaşımlı depolama kullanıyorsanız yalnızca bellek taşınır ve süre saniyelerle ölçülür. Yerel disk kullanıyorsanız disk de kopyalanacağı için süre disk boyutuna ve ağ hızına bağlı olarak dakikalardan saatlere çıkabilir. Kaba bir tahmin için taşınacak toplam veriyi ağın gerçek aktarım hızına bölün ve bellek kirletme hızı için bir miktar pay ekleyin.

LXC konteynerleri canlı göç edilebilir mi#

Hayır. Konteynerler konak çekirdeğini paylaştığı için bellek durumları taşınamaz; Proxmox konteyneri hedef düğümde yeniden başlatarak taşır ve bunun için --restart bayrağı gerekir. Kesintisiz taşınması gereken iş yüklerini konteyner yerine tam sanal makine olarak çalıştırmak daha uygundur.

Göç için paylaşımlı depolama zorunlu mu#

Canlı göç için zorunlu değildir; --with-local-disks bayrağıyla yerel diskli makineleri de taşıyabilirsiniz, sadece çok daha uzun sürer. Ancak yüksek erişilebilirlik için paylaşımlı depolama gerçekten zorunludur, çünkü çöken bir düğümün yerel diskindeki veriye diğer düğümler erişemez ve HA makineyi başka yerde açamaz.

Göç trafiğini neden ayrı ağa almalıyım#

Çünkü göç, ağı tamamen doyurabilecek tek işlemdir. Aynı hattan corosync geçiyorsa düğümler birbirini kaybeder, küme quorum düşürür ve HA etkinse sunucular kendini yeniden başlatır — yani rutin bir bakım işlemi kümeyi çökertir. /etc/pve/datacenter.cfg içindeki migration satırıyla ayrı bir ağ tanımlamak, bu riski tek satırda ortadan kaldırır.

Kapanış#

Canlı göç, bir Proxmox kümesini "birkaç sunucu" olmaktan çıkarıp gerçekten yönetilebilir bir altyapıya dönüştüren özelliktir; donanım bakımını, çekirdek güncellemelerini ve yük dengelemeyi kesintisiz yapabilmeniz demektir. Aklınızda tutmanız gereken dört şey var: göç ağını mutlaka ayırın, host CPU tipinden kaçınıp kümede ortak bir model seçin, köprü isimlerini tüm düğümlerde aynı tutun ve paylaşımlı depolamanın göç süresini saatlerden saniyelere indirdiğini unutmayın.

Göçü otomatikleştirip bir düğüm çöktüğünde makinelerin kendiliğinden başka düğümde açılmasını istiyorsanız bir sonraki adım Proxmox HA kurulumu olmalı. Küme kuracağınız donanım arıyorsanız dedicated sunucu ve colocation seçeneklerimize göz atabilir, kendi kümenizi işletmek istemiyorsanız hazır bulut sunucu ve VDS paketlerimizi değerlendirebilirsiniz. Küme bakımını devretmek isterseniz sunucu yönetimi hizmetimiz bu işi üstlenir.