Azure Migrate’in “Migration and modernization” aracıyla VMware VM’lerini taşımanın iki yolu var: agent kurmadan çalışan agentless replication ve her sunucuya bir agent kuran agent-based replication. Bu yazıda ikincisinin mimarisini, replikasyon akışını, port gereksinimlerini ve ölçeklendirme limitlerini detaylı şekilde ele alıyoruz. Agent-based yaklaşım arka planda Azure Site Recovery servisinin bazı yeteneklerini kullanıyor.
Agent-based migration nedir, ne zaman kullanılır?
Agent-based migration, on-premises VMware VM’lerini ve fiziksel sunucuları Azure’a taşımak için kullanılıyor. Kapsamı bununla da sınırlı değil; diğer on-premises sanallaştırılmış sunucular ile private ve public cloud VM’leri de bu yöntemle taşınabiliyor. Buna AWS instance’ları ve GCP VM’leri de dahil.
Yani AWS’den Azure’a ya da GCP’den Azure’a taşıma yapacaksanız agent-based, elinizdeki tek pratik yol oluyor. VMware ortamında ise agentless ile agent-based arasında seçim yapma lüksünüz var.
Mimari bileşenler
Replication appliance (Configuration server + Process server)
On-premises ortam ile Migration and modernization aracı arasında köprü görevi gören bir on-premises sunucu. Appliance, on-premises sunucu envanterini keşfediyor ki araç replikasyon ve migration’ı orkestre edebilsin. İki bileşenden oluşuyor:
- Configuration server: Migration and modernization aracına bağlanıyor ve replikasyonu koordine ediyor.
- Process server: Veri replikasyonunu yönetiyor. Sunucu verisini alıyor, sıkıştırıyor, şifreliyor ve Azure’a gönderiyor. Azure tarafında araç bu veriyi managed disk’lere yazıyor.
Varsayılan olarak process server, configuration server ile birlikte aynı replication appliance üzerinde kurulu geliyor.
Mobility service
Replike edip taşımak istediğiniz her sunucuya kurulan agent. Replikasyon verisini sunucudan process server’a gönderiyor. Farklı sürümlerin kurulum dosyaları replication appliance üzerinde bulunuyor; replike edeceğiniz sunucunun işletim sistemi ve sürümüne göre uygun agent’ı indirip kuruyorsunuz.
Mobility service kurulum yöntemleri
- Push installation: Bir sunucu için koruma etkinleştirildiğinde process server Mobility service’i otomatik kuruyor.
- Manuel kurulum: Her sunucuya UI veya komut satırı üzerinden elle kurabiliyorsunuz.
Antivirüs istisnaları (kritik detay)
Replication appliance, process server veya replike edilen sunucularda antivirüs yazılımı çalışıyorsa aşağıdaki klasörlerin tarama dışında bırakılması gerekiyor. Bu, sahada en sık atlanan ve replikasyon hatalarına yol açan konfigürasyon adımlarından biri:
C:\Program Files\Microsoft Azure Recovery Services AgentC:\ProgramData\ASRC:\ProgramData\ASRLogsC:\ProgramData\ASRSetupLogsC:\ProgramData\LogUploadServiceLogsC:\ProgramData\Microsoft Azure Site RecoveryC:\Program Files (x86)\Microsoft Azure Site RecoveryC:\ProgramData\ASR\agent(Mobility service kurulu Windows sunucularda)
Replikasyon süreci adım adım
- Bir sunucu için replikasyon etkinleştirildiğinde Azure’a initial replication başlıyor.
- Initial replication sırasında Mobility service sunucu disklerinden veriyi okuyup process server’a gönderiyor.
- Bu veri, Azure aboneliğinizde diskin bir kopyasını oluşturmak (seed) için kullanılıyor.
- Initial replication bittikten sonra Azure’a delta değişikliklerin replikasyonu başlıyor. Replikasyon block-level ve neredeyse sürekli (near-continuous).
- Mobility service, işletim sisteminin storage subsystem’ine entegre olarak disk belleğine yapılan yazma işlemlerini yakalıyor. Bu yöntem sayesinde incremental replikasyon için replike edilen sunucuda ek disk I/O operasyonu oluşmuyor.
- Bir sunucu için takip edilen değişiklikler HTTPS 9443 inbound portundan process server’a gönderiliyor (bu port değiştirilebilir). Process server veriyi sıkıştırıp şifreliyor ve Azure’a gönderiyor.
Port gereksinimleri
- Replike edilen sunucular: VM’lerde çalışan Mobility service, replikasyon yönetimi için on-premises replication appliance ile HTTPS 443 inbound üzerinden haberleşiyor. Replikasyon verisini ise process server’a HTTPS 9443 inbound ile gönderiyor (değiştirilebilir).
- Replication appliance: Azure ile replikasyonu HTTPS 443 outbound üzerinden orkestre ediyor.
- Process server: Replikasyon verisini alıp optimize ve şifreledikten sonra Azure storage’a port 443 outbound ile gönderiyor.
Performans ve ölçeklendirme
Varsayılan kurulumda tek bir replication appliance hem configuration server hem process server’ı çalıştırıyor. Az sayıda sunucu replike ediyorsanız bu yeterli. Ancak yüzlerce sunucu taşıyorsanız tek bir process server tüm replikasyon trafiğini kaldıramayabilir. Bu durumda ek scale-out process server‘lar deploy edebiliyorsunuz.
Ek process server gerekip gerekmediğini belirlemede iki temel eşik var:
- Günlük değişim oranı (churn rate) 2 TB’ı geçiyorsa ek bir process server deploy edin.
- 200’den fazla sunucu replike ediyorsanız ek bir replication appliance deploy edin.
Replication appliance kapasite tablosu
- 8 vCPU (2 socket × 4 core @ 2.5 GHz), 16 GB RAM, 300 GB boş alan: 500 GB veya altı churn, < 100 sunucu
- 12 vCPU (2 socket × 6 core @ 2.5 GHz), 18 GB RAM, 600 GB boş alan: 501 GB – 1 TB churn, 100-150 sunucu
- 16 vCPU (2 socket × 8 core @ 2.5 GHz), 32 GB RAM, 1 TB boş alan: 1 TB – 2 TB churn, 151-200 sunucu
Scale-out process server boyutlandırma
- 4 vCPU (2 socket × 2 core @ 2.5 GHz), 8 GB RAM, 300 GB cache: 250 GB veya altı churn, 85 sunucuya kadar
- 8 vCPU (2 socket × 4 core @ 2.5 GHz), 12 GB RAM, 600 GB cache: 251 GB – 1 TB churn, 86-150 sunucu
- 12 vCPU (2 socket × 6 core @ 2.5 GHz), 24 GB RAM, 1 TB cache: 1-2 TB churn, 151-225 sunucu
VMware ortamları için Microsoft, günlük veri değişim oranını ve ihtiyaç duyulan process server sayısını belirlemek üzere Site Recovery Deployment Planner for VMware aracını öneriyor.
Upload bant genişliği kısıtlama (throttling)
Azure’a replike olan VMware trafiği belirli bir process server üzerinden geçtiği için, upload throughput’unu process server üzerinde kısıtlayabiliyorsunuz. İki yöntem var:
1. Registry ile thread sayısı:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication\UploadThreadsPerVMBu değer bir diskin veri transferi (initial veya delta replikasyon) için kullanılan thread sayısını belirtiyor. Yüksek değer replikasyon için kullanılan ağ bant genişliğini artırıyor. Varsayılan 4, maksimum 32. Optimize etmek için trafiği izlemeniz öneriliyor.
2. Azure Backup MMC snap-in ile throttling:
- Process server’da Azure Backup MMC snap-in’i açın (masaüstünde kısayol ya da
C:\Program Files\Microsoft Azure Recovery Services Agent\binaltında) - Change Properties seçin
- Throttling sekmesinde “Enable internet bandwidth usage throttling for backup operations” işaretleyin
- Mesai saatleri ve mesai dışı saatler için limitleri ayarlayın. Geçerli aralık: 512 Kbps – 1.023 Mbps
Agent-based migration, agentless yönteme göre daha fazla kurulum eforu gerektiriyor (her sunucuya Mobility service kurulumu, appliance boyutlandırması, port açma, antivirüs istisnaları). Buna karşılık AWS ve GCP gibi VMware dışı kaynaklardan taşıma yapabilme ve block-level near-continuous replikasyonun getirdiği düşük RPO gibi avantajlar sunuyor. Özellikle churn rate’i yüksek, sürekli yazma yapan veritabanı sunucuları için agent-based yaklaşım daha öngörülebilir sonuçlar verebiliyor. Pratik öneri: projeye başlamadan önce Deployment Planner ile churn rate ölçümü yapmak ve appliance boyutlandırmasını buna göre planlamak, migration ortasında performans darboğazına girmenin önüne geçiyor. 200 sunucu ve 2 TB churn eşiklerini de baştan takvimlemek, scale-out ihtiyacını sürpriz olmaktan çıkarıyor.
Kaynak: https://learn.microsoft.com/en-us/azure/migrate/agent-based-migration-architecture?view=migrate
