Canlı Göç: Proxmox Üzerinde VM ve Konteyner Migration İşlemleri

yazar

Üretim ortamında çalışan bir sistemi kapatmadan başka bir sunucuya taşımak, sysadmin’lerin en çok sevdiği büyü türlerinden biri. Proxmox üzerinde canlı göç (live migration) tam olarak bunu sağlıyor: VM ya da konteyner ayağa kalkmış, kullanıcılar bağlı, servisler çalışıyor… ve siz arka planda her şeyi başka bir fiziksel makineye taşıyorsunuz. Bu yazıda hem VM hem LXC konteyner migration işlemlerini, öncesinde yapılması gerekenleri, sık karşılaşılan hataları ve gerçek dünya senaryolarını ele alacağız.

Canlı Göç Nedir, Ne Zaman Gerekir?

Canlı göç, çalışan bir sanal makinenin veya konteynerin hafıza içeriğini, disk durumunu ve ağ bağlantılarını minimum kesinti ile başka bir fiziksel sunucuya aktarma işlemidir. Proxmox bu işlemi KVM için QEMU’nun yerleşik live migration altyapısı üzerinden, LXC konteynerler için ise kernel checkpoint mekanizmaları aracılığıyla gerçekleştirir.

Tipik kullanım senaryoları şunlar:

  • Fiziksel sunucu bakımı veya donanım değişimi öncesi
  • Yük dengeleme, bir node’un CPU/RAM’i dolduğunda
  • Depolama migrasyonu, eski disk arrayi yenisiyle değiştirirken
  • Planlı Proxmox sürüm yükseltmeleri
  • Güç tasarrufu, geceleri boşta kalan node’ları kapatmak için VM’leri konsolide etme

Burada önemli bir ayrım var: canlı göç (live migration) ile soğuk göç (cold migration) farklı şeyler. Soğuk göç, VM’i kapatıp taşımak demek. Canlı göç ise VM çalışırken gerçekleşiyor ve kullanıcılar birkaç saniyelik ağ kesintisi dışında hiçbir şey fark etmiyor.

Ön Koşullar ve Hazırlık

Migration başlamadan önce ortamın doğru yapılandırıldığından emin olmanız gerekiyor. En sık atlandığı için en çok sorun çıkaran adımlar bunlar.

Cluster Yapısı ve Node İletişimi

Canlı göç için Proxmox cluster kurulu olması zorunlu. İki node tek başına çalışıyorsa migration yapamazsınız.

# Cluster durumunu kontrol et
pvecm status

# Node'ların birbirini görüp görmediğini test et
pvecm nodes

# Node'lar arası ping testi (corosync için önemli)
ping -c 4 192.168.1.102

Çıktıda tüm node’ların “online” göründüğünden emin olun. Bir node “offline” görünüyorsa migration başlatmak işe yaramaz.

Paylaşımlı Depolama Zorunluluğu

KVM VM’leri için canlı göç, paylaşımlı depolama olmadan çalışmaz. Bu en temel gereksinim. Eğer VM diski yerel depolamada (local-lvm, local) duruyorsa, canlı göç yerine soğuk göç veya depolama migrasyonu yapmanız gerekir.

Paylaşımlı depolama seçenekleri:

  • NFS: Kurulumu kolay, küçük/orta ortamlar için yeterli
  • Ceph: Proxmox’un yerleşik çözümü, en iyi entegrasyon
  • iSCSI: Kurumsal SAN altyapılarıyla uyumlu
  • GlusterFS: Açık kaynak, dağıtık depolama
# Mevcut depolama havuzlarını listele
pvesm status

# Hangi storage'ın hangi node'larda aktif olduğunu gör
pvesm status --storage ceph-pool

# NFS paylaşım eklemek için (tüm cluster'a)
pvesm add nfs shared-nfs --server 192.168.1.200 --export /data/proxmox --options vers=4

LXC konteynerler ise yerel depolamadan da canlı göç yapabilir, ancak bu özellik deneysel sayılır ve her zaman sorunsuz çalışmayabilir.

Ağ Yapılandırması

Kaynak ve hedef node’da aynı ağ köprüsü (bridge) isimlerinin mevcut olması gerekiyor. VM vmbr0‘a bağlıysa, hedef node’da da vmbr0 tanımlı olmalı.

# Kaynak node'daki ağ arayüzlerini gör
cat /etc/network/interfaces

# Hedef node'un ağ yapısını kontrol et
ssh 192.168.1.102 "cat /etc/network/interfaces"

# Eğer aynı VLAN tag'leri kullanılıyorsa onları da doğrula
bridge vlan show

VM Canlı Göçü: Adım Adım

Web Arayüzü ile Migration

En kolay yol web arayüzü. VM’e sağ tıklayın, “Migrate” seçin, hedef node’u belirleyin ve “Migrate” butonuna basın. Ama biz sysadmin’iz, komut satırını kullanacağız.

Komut Satırından VM Migration

# Temel migration komutu
# qm migrate <vmid> <hedef-node> --online
qm migrate 101 pve-node2 --online

# Migration durumunu izlemek için
qm migrate 101 pve-node2 --online 2>&1 | tee /var/log/migration-101.log

# Disk de farklı storage'a taşınacaksa
qm migrate 101 pve-node2 --online --targetstorage ceph-pool

# Migration bandwidth limitini belirle (MB/s cinsinden)
qm migrate 101 pve-node2 --online --bwlimit 512

--online parametresi olmadan komut verirseniz, Proxmox VM’i önce durdurup sonra taşır (soğuk göç). Canlı göç istiyorsanız bu parametreyi unutmayın.

Migration Sürecini İzleme

Migration sırasında neler olduğunu anlamak önemli. QEMU önce VM’in bellek sayfalarını hedef node’a kopyalamaya başlar. VM çalışmaya devam ettiği için bazı sayfalar değişir, bunlar tekrar kopyalanır. Bu süreç yeterince az sayfa kalana kadar devam eder ve ardından çok kısa bir “freeze” anında son sayfalar aktarılır, kontrol hedef node’a geçer.

# Migration progress'i task log'lardan takip et
tail -f /var/log/pve/tasks/active

# Alternatif olarak
journalctl -u pvedaemon --follow | grep -i migrat

# Belirli bir task'ın detayına bak
cat /var/log/pve/tasks/UPID:pve-node1:...

Sorunlu Migration Senaryoları

Senaryo 1: Migration başlıyor ama hiç bitmiyor

Bu genellikle yoğun yazma aktivitesi olan bir VM’de yaşanır. Database sunucusu gibi sürekli bellek yazan bir VM, QEMU’nun dirty page sayısını düşürememesine neden olur.

# VM'in bellek yazma hızını gör
virsh dommemstat 101

# Alternatif: Migration sırasında convergence bilgisini izle
# Proxmox migration log'larında "remaining" değerinin düşüp düşmediğine bak
grep "remaining" /var/log/pve/tasks/UPID:pve-node1:...

Çözüm olarak VM’deki yüksek yazma işlemlerini geçici olarak yavaşlatmak (örneğin database maintenance mode’a almak) ya da soğuk göç yapmak düşünülebilir.

Senaryo 2: “migration precondition failed” hatası

# Hata mesajının tamamını gör
qm migrate 101 pve-node2 --online 2>&1

# Yaygın nedenler:
# 1. Hedef node'da yeterli RAM yok
free -h
ssh pve-node2 "free -h"

# 2. CPU tipi uyumsuzluğu - check host CPU flags
grep flags /proc/cpuinfo | head -1

# 3. VM'e bağlı yerel cihaz var (USB passthrough gibi)
qm config 101 | grep -i usb

LXC Konteyner Migration İşlemleri

LXC migration, VM migration’dan biraz farklı çalışır. Konteynerler kernel’i host ile paylaştığı için bazı kısıtlamalar var.

Temel LXC Migration Komutları

# LXC konteyner canlı göçü
pct migrate 200 pve-node2 --online

# Yerel depolamadan paylaşımlı depolamaya taşıyarak migrate et
pct migrate 200 pve-node2 --online --targetstorage ceph-pool

# Restart migration (kısa kesinti ile ama daha güvenilir)
pct migrate 200 pve-node2 --restart

# Timeout süresini artır (büyük konteynerler için)
pct migrate 200 pve-node2 --online --timeout 300

--restart seçeneği canlı göç değildir ama --online‘dan daha güvenilirdir. Konteyner durdurulur, taşınır ve hedef node’da yeniden başlatılır. Kritik olmayan konteynerler için makul bir seçenek.

LXC İçin Özel Durumlar

Bazı konteyner konfigürasyonları canlı göcü engeller:

# Konteynerin config'ini incele
pct config 200

# Sorunlu olabilecek ayarlar:
# - lxc.cgroup olarak ayarlanmış bazı cgroup değerleri
# - Bind mount'lar (yerel dizin bağlamaları)
# - Ayrıcalıklı (privileged) konteynerler
pct config 200 | grep -E "unprivileged|mp[0-9]"

Bind mount içeren konteyner: Eğer konteynerde yerel bir dizini mount eden ayar varsa (mp0: /mnt/data,...) bu dizin hedef node’da da aynı yerde mevcut değilse migration başarısız olur.

# Bind mount'u geçici olarak kaldır
pct set 200 --delete mp0

# Migration'ı yap
pct migrate 200 pve-node2 --online

# Migration sonrası hedef node'da mount'u yeniden ekle
pct set 200 --mp0 /mnt/data,mp=/data

Depolama Migrasyonu ile Birlikte Kullanım

Gerçek hayatta en sık ihtiyaç duyulan senaryo: VM hem farklı node’a hem farklı storage’a taşınacak. Örneğin local-lvm’den Ceph’e geçiş.

# VM'i hem farklı node'a hem farklı storage'a taşı
qm migrate 101 pve-node2 --online --targetstorage ceph-pool

# Sadece disk'i farklı storage'a taşı (node değişmeden)
qm move-disk 101 scsi0 ceph-pool --delete

# Disk taşındıktan sonra migration yap
qm migrate 101 pve-node2 --online

Disk migrasyonu sırasında VM çalışmaya devam eder ama bu işlem yavaş olabilir. 100GB’lık bir disk için ağ hızına bağlı olarak 10-30 dakika beklemeniz normal.

# Disk migration progress'ini izle
watch -n 2 "pvesm list ceph-pool | grep vm-101"

# Task log'unu takip et
tail -f /var/log/pve/tasks/active

Toplu Migration: Birden Fazla VM’i Taşıma

Bir node’u bakıma almadan önce üzerindeki tüm VM’leri taşımanız gerekiyor. Bunu tek tek yapmak yerine script kullanalım.

#!/bin/bash
# Belirli bir node'daki tüm VM'leri başka node'a taşı

SOURCE_NODE="pve-node1"
TARGET_NODE="pve-node2"
TARGET_STORAGE="ceph-pool"

echo "=== Migration başlıyor: $SOURCE_NODE -> $TARGET_NODE ==="

# Bu node'daki tüm VM ID'lerini al
VM_LIST=$(pvesh get /nodes/$SOURCE_NODE/qemu --output-format json | 
  python3 -c "import sys,json; [print(v['vmid']) for v in json.load(sys.stdin)]")

for VMID in $VM_LIST; do
  echo "Taşınıyor: VM $VMID"
  qm migrate $VMID $TARGET_NODE --online --targetstorage $TARGET_STORAGE
  
  if [ $? -eq 0 ]; then
    echo "VM $VMID başarıyla taşındı"
  else
    echo "HATA: VM $VMID taşınamadı!" >&2
  fi
  
  # Node'u bunaltmamak için kısa bekleme
  sleep 10
done

echo "=== Tüm migration işlemleri tamamlandı ==="

LXC konteynerler için de benzer bir script:

#!/bin/bash
# Tüm LXC konteynerlerini toplu migrate et

TARGET_NODE="pve-node2"

CT_LIST=$(pvesh get /nodes/$(hostname)/lxc --output-format json | 
  python3 -c "import sys,json; [print(c['vmid']) for c in json.load(sys.stdin)]")

for CTID in $CT_LIST; do
  STATUS=$(pct status $CTID | awk '{print $2}')
  
  if [ "$STATUS" == "running" ]; then
    echo "Canlı migrate: CT $CTID"
    pct migrate $CTID $TARGET_NODE --online --timeout 120
  else
    echo "Soğuk migrate: CT $CTID (durmuş)"
    pct migrate $CTID $TARGET_NODE
  fi
done

HA (Yüksek Erişilebilirlik) ile Migration İlişkisi

Proxmox HA cluster’ında VM’ler otomatik olarak migrate edilebilir. Bir node çökerse HA manager diğer node’larda VM’leri yeniden başlatır. Ama bu canlı göç değil, crash recovery’dir.

# HA durumunu kontrol et
ha-manager status

# Bir VM'i HA grubuna ekle
ha-manager add vm:101 --group production-group --max_restart 3

# HA migration'ı manuel tetikle (bakım modu için)
# Önce node'u maintenance moduna al
pvecm maintenance on pve-node1

# Bu komut node üzerindeki tüm HA-managed VM'leri otomatik taşır
# Bakım bittikten sonra
pvecm maintenance off pve-node1

Migration Sonrası Doğrulama

Migration tamamlandı ama işimiz bitmedi. Her şeyin doğru çalıştığını teyit etmemiz gerekiyor.

# VM'in şu an hangi node'da olduğunu doğrula
pvesh get /cluster/resources --type vm | grep -i "vm-101"

# VM içinden kontrol (SSH ile bağlanıp)
# Network bağlantısını test et
ping -c 4 8.8.8.8

# Servis durumlarını kontrol et
systemctl --failed

# Disk I/O'nun düzgün çalıştığını test et
dd if=/dev/zero of=/tmp/test bs=1M count=512 oflag=direct
rm /tmp/test

# Network throughput testi
iperf3 -c iperf-server-ip

# Migration sonrası VM'in uptime'ı (sıfırlanmamış olmalı)
uptime

Canlı göçte uptime sıfırlanmamalı. Eğer sıfırlanmışsa migration sırasında VM yeniden başlamış demektir, bu bir sorun işareti.

Gerçek Dünya Senaryosu: Acil Disk Arızası

Gece 02:00, monitorinig sisteminizden alarm geliyor: pve-node1 üzerindeki RAID dizisinde disk hataları var. O node üzerinde 8 VM çalışıyor. Panik yapmadan adım adım:

# Önce durumu değerlendir
dmesg | tail -50 | grep -i "error|fail|scsi"
smartctl -a /dev/sdb

# Disk gerçekten ölmeden önce ne kadar zamanımız var?
# smartctl çıktısındaki Reallocated Sector Count'a bak

# Hemen tüm VM'leri node2'ye taşımaya başla (önce kritik olanlar)
qm migrate 101 pve-node2 --online  # Production web server
qm migrate 102 pve-node2 --online  # Database

# Migration sırasında disk okuma yazma stresini azalt
# (Diğer VM'leri geçici olarak suspend et)
qm suspend 105
qm suspend 106

# Kritikler taşındıktan sonra gerisini taşı
for vmid in 103 104 105 106 107 108; do
  qm migrate $vmid pve-node2 --online
  sleep 5
done

# Tüm VM'ler taşındı, node1'i kapat
ssh pve-node1 "shutdown -h now"

Bu senaryoda bant genişliği yönetimi kritik. Çok fazla paralel migration başlatırsanız hem ağı hem de arızalı diski daha çok zorlarsınız.

Migration Performans Optimizasyonu

# Migration için ayrı bir ağ arayüzü kullan
# /etc/pve/datacenter.cfg dosyasına ekle
cat >> /etc/pve/datacenter.cfg << EOF
migration: type=insecure,network=10.10.10.0/24
EOF

# Bu ayar migration trafiğini 10.10.10.0/24 ağından geçirir
# Üretim trafiğini ve migration trafiğini ayırmış olursunuz

# Şifreli migration yerine şifresiz (insecure) kullanmak hızı artırır
# Ama bunu sadece güvenilir iç ağda yapın!

# Migration bandwidth limitini artır
# /etc/pve/datacenter.cfg
echo "bwlimit: 0" >> /etc/pve/datacenter.cfg
# 0 = limitsiz, sayı girilirse MB/s cinsinden limit koyar

Proxmox varsayılan olarak şifreli migration yapar. Aynı veri merkezinde güvendiğiniz bir ağ üzerindeyseniz insecure modu CPU yükünü önemli ölçüde azaltır ve hızı artırır.

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

“no common storage found” hatası:

# Her iki node'un da aynı storage'ı görmesi gerekiyor
pvesm status
ssh pve-node2 "pvesm status"

# Storage aktif değilse yeniden aktive et
pvesm activate ceph-pool

“target ‘pve-node2’ is not online” hatası:

pvecm status
# Node gerçekten offline ise önce onu düzelt
# Node online ama cluster sorunu varsa:
systemctl restart corosync
systemctl restart pve-cluster

LXC migration’da “criu dump failed” hatası:

CRIU (Checkpoint/Restore In Userspace) LXC live migration için kullanılır. Bazı uygulamalar CRIU ile uyumlu değil.

# CRIU desteğini kontrol et
criu check

# Sorunlu process'leri bul
criu dump -t $(pct pid 200) --log-level 4 --log-file /tmp/criu.log 2>&1
cat /tmp/criu.log | grep -i error

# Alternatif: restart migration kullan (criu gerektirmez)
pct migrate 200 pve-node2 --restart

Sonuç

Proxmox üzerinde canlı göç, doğru yapılandırılmış bir ortamda gerçekten sorunsuz çalışan, üretim hayatını kolaylaştıran bir özellik. Önemli noktalara tekrar değinmek gerekirse: VM canlı göçü için paylaşımlı depolama şart, ağ köprü isimleri eşleşmeli ve cluster sağlıklı olmalı. LXC konteynerler daha esnek ama CRIU uyumluluğu konusunda test yapmanızı öneririm.

Acil bir disk arızasında veya planlı bakım öncesinde bu adımları otomasyona dökmek, gece 02:00’da panik yerine sakin bir şekilde birkaç komut çalıştırmanızı sağlar. Migration scriptlerinizi önceden test edin, monitörlerinizi kurun ve migration trafiği için ayrı bir ağ arayüzü ayarlayın. Bu üç önlem, migration işlemlerini tahmin edilebilir ve güvenilir hale getirir.

Son olarak: migration’ı ilk kez üretimde denemeyin. Test ortamınızda farklı senaryoları deneyin, hangi VM’lerin sorun çıkarabileceğini öğrenin ve ardından üretimde uygulayın.

Yorum yapın