VMware'den Skypium'a ajansız geçiş: teknik rehber

Bir sanallaştırma ortamından bulut altyapısına geçiş genellikle iki korkuyla ertelenir: uzun bir kesinti penceresi ve geri dönüşü olmayan bir adım. Ajansız göç modeli her ikisini de ortadan kaldırmayı hedefler — kaynak ortamınıza herhangi bir yazılım kurmadan, sanal makineleri çalışır durumdayken okuyup hedef bulutta yeniden ayağa kaldırır. Bu yazıda göç aracının teknik akışını, kesinti penceresini ve geçiş öncesi/sonrası yapılması gerekenleri adım adım ele alıyoruz.

Ajansız geçiş nasıl çalışır

“Ajansız” ifadesi, taşınacak sanal makinenin içine herhangi bir ajan yazılımı kurulmadığı anlamına gelir. Göç aracı, sanallaştırma platformunun yönetim katmanına (vCenter) doğrudan bağlanır ve disklerin bir anlık görüntüsünü (snapshot) alır. Bu görüntü, kaynak makine çalışmaya devam ederken diskin o andaki tutarlı halini temsil eder; snapshot alma işlemi saniyeler sürer ve sunucuyu durdurmaz.

Aktarım üç aşamada ilerler:

1. Snapshot alma — kaynak sanal makinenin diskleri için tutarlı bir başlangıç noktası oluşturulur.
2. Değişen blok aktarımı — disk, sabit boyutlu parçalara (chunk) bölünerek hedefe kopyalanır. İlk kopyalama tüm diski kapsar; snapshot sonrası oluşan yeni yazmalar ayrıca izlenir ve yalnızca değişen bloklar tekrar aktarılır. Bu sayede büyük disklerde bile aktarım süresi disk boyutuyla değil, gerçek veri değişim hızıyla orantılı kalır.
3. Önyükleme — aktarım tamamlandığında disk, hedef bulutta doğrudan diskten önyükleme yapan (boot-from-volume) bir sunucuya bağlanır. Ayrı bir imaj oluşturma veya format dönüştürme adımı yoktur; disk aynen bulut ortamına taşınır.

Aktarım sırasında ağ bağlantısı koparsa işlem baştan başlamaz — kaldığı chunk’tan devam eder. Bu, özellikle büyük disklerin veya sınırlı bant genişliğine sahip ortamların göçünde kritik bir güvencedir; gece başlatılan bir aktarımın sabah bağlantı kesintisi yüzünden sıfırdan tekrarlanması gerekmez.

Hem Windows hem Linux sanal makineleri aynı akıştan geçer — disk seviyesinde çalışan bir aktarım olduğu için işletim sistemi göç mantığını değiştirmez, yalnızca önyükleme sonrası sürücü/agent kontrolleri farklılaşır.

Kesinti penceresi ne kadar sürer

Aktarımın büyük kısmı kaynak makine çalışırken, arka planda gerçekleşir — bu adımda hiçbir kesinti yoktur. Gerçek kesinti yalnızca son geçiş (cutover) adımında yaşanır: kaynak makine kısa süreliğine durdurulur, snapshot sonrası oluşan son değişiklikler de aktarılır, ardından hedef sunucu Skypium’da başlatılır. Bu son adım, disk boyutundan bağımsız olarak genellikle dakikalar sürer, çünkü aktarılacak veri yalnızca son senkronizasyon farkıdır — tüm disk değil.

Kesinti penceresinin süresi iki faktöre bağlıdır: kaynak makinenin o andaki yazma yoğunluğu ve ağ hızı. Düşük yazma yoğunluğuna sahip bir sunucuda (örneğin durağan bir dosya sunucusu) fark neredeyse sıfıra yakınken, yoğun veritabanı yükü olan bir sunucuda son senkronizasyon birkaç dakika sürebilir. Bu yüzden kritik veritabanı sunucularını, göreceli olarak daha sakin bir zaman dilimine planlamak son senkronizasyonu kısaltır.

Geçiş öncesi kontrol listesi

Göçün sorunsuz ilerlemesi için birkaç adımın önceden netleştirilmesi gerekir:

• Envanter çıkarın. Taşınacak sanal makinelerin listesini, her birinin disk sayısını ve boyutunu, işletim sistemini ve bağımlılıklarını (hangi sunucunun hangisine bağlı çalıştığını) çıkarın.
• Disk formatlarını doğrulayın. Göç aracı VMDK disklerini doğrudan okur; farklı bir sanallaştırma platformundan geliyorsanız önce dönüştürme gerekip gerekmediğini kontrol edin.
• Önyükleme modunu (BIOS/UEFI) doğrulayın. Kaynak sanal makinenin BIOS mı yoksa UEFI ile mi ayağa kalktığını taşımadan önce netleştirin; hedef ortamdaki sunucu bu moda göre oluşturulur. Uyumsuz bir eşleşme, disk aktarımı sorunsuz tamamlansa bile önyüklemenin ilk adımda başarısız olmasına yol açabilir — bu kontrolü cutover sonrasına bırakmak yerine envanter aşamasında yapmak, planlanan kesinti penceresinin dışında beklenmedik bir gecikmeyi önler.
• Ağ planı yapın. Hedef ortamdaki ağ adreslemesinin kaynak ortamla nasıl eşleşeceğini (aynı IP aralığı mı, yeni bir VPC mi) önceden belirleyin — bu, cutover sonrası bağlantı sorunlarının en sık nedenidir.
• Aktarım süresini kabaca hesaplayın. İlk kopyalama tüm diski kapsadığından süre, disk boyutu ile kaynak-hedef arası kullanılabilir bant genişliğine bağlıdır; örneğin 500 GB’lık bir disk için gerçek aktarım hızını (genellikle nominal bağlantı hızının altında kalır) baz alan kaba bir bölme işlemi, ilk kopyalamanın kaç saat süreceğine dair gerçekçi bir beklenti verir. Bu tahmin, aktarımı iş saatleri dışında başlatma kararını daha isabetli hale getirir.
• Test planı hazırlayın. Her sunucu için, geçiş sonrası “çalışıyor” kabul edilecek somut kontrolleri (servis erişimi, veritabanı bağlantısı, arka plan görevleri) yazılı hale getirin.
• Taşıma sırasını belirleyin. Bağımlılığı düşük sunucularla başlayıp süreci öğrenin, kritik sunucuları en son ve en tecrübeli olduğunuz anda taşıyın.

Aktarım sırasında ilerleme, chunk bazında izlenebilir bir günlük olarak görülür:

transfer: disk0 chunk 128/512 aktarıldı — 6.4 GB / 512 GB
transfer: disk0 delta-sync tamamlandı — 3 chunk değişti
cutover: kaynak durduruldu, son senkronizasyon başladı
cutover: hedef sunucu Skypium'da başlatıldı

Bu sıralama, göç aracının arka planda izlediği akışı olduğu gibi yansıtır — hangi aşamada olduğunuzu bilmek, cutover zamanlamasını doğru planlamanıza yardımcı olur.

Geri dönüş planı

Ajansız göçün en önemli özelliklerinden biri, kaynak ortamınıza dokunmamasıdır. Snapshot alma ve chunk aktarımı sırasında kaynak sanal makine değişmeden, olduğu gibi çalışmaya devam eder. Bu da geri dönüşü basitleştirir: cutover onaylanana kadar kaynak makineniz canlı kalır; yeni sunucuyu test edip sorun bulursanız hiçbir şeyi geri almanıza gerek kalmadan kaynağa dönebilirsiniz. Geri dönüş burada “eski haline getirme” değil, sadece “henüz cutover yapmama” kararıdır.

Cutover sonrası bir sorun tespit edilirse de kaynak makine bir süre daha durur halde tutulabilir; gerekirse tekrar başlatılıp trafik eski ortama yönlendirilebilir. Bu yüzden cutover’dan önce test planının eksiksiz çalıştırılması, geri dönüş ihtiyacını en aza indirir.

Geçiş sonrası doğrulama

Sunucu Skypium’da ayağa kalktıktan sonra üç kontrolü atlamayın: disk bütünlüğü (dosya sistemi hatasız monte oluyor mu), ağ bağlantısı (yeni adresleme ile hedeflenen servislere erişim var mı) ve uygulama katmanı (veritabanı, arka plan servisleri beklenen şekilde çalışıyor mu). Bu üç kontrol geçtiğinde göç tamamlanmış sayılır ve kaynak makineyi kapatma kararını güvenle verebilirsiniz.

Ortamınızı taşımaya hazırsanız, disk envanterinizi ve zaman çizelgenizi birlikte değerlendirmek için demo talebi oluşturun — göç akışını kendi sunucularınızla birlikte planlayalım.