(ASM) Classic Portaldaki Sanal Makinelerinizi Resource Manager ‘a (ARM) Taşıyın

Merhabalar,
Bu makalemizde Azure üzerinde barındırılan sanal makine dağıtımıın Classic portal üzerinden Yeni portala (Azure Resource Manager) nasıl taşınacağına değineceğim.
Taşıma senaryolarında kullanılan çözümlerden biri olan Migaz aracını kullanarak taşıma işlemini gerçekleştireceğim. Dilerseniz sanal makilerinizi ARM’ye ve ya CSP (Cloud Solution Proveider) aboneliğine taşıyabilirsiniz.
Ben classic portal üzerinde taşıma işlemi için oluşturduğum sanal makinemi ARM ‘ye geçireceğim.
Dağıtım işlemine başlamadan önce hazır olarak bulundurmamız gereken bileşenlere bakalım ;
• Azure ve AzureRM PowerShell modüllerinin en son sürümüne ihtiyacımız vardır.
• MigAz zip dosyasını indirelim ve rar’dan çıkartalım.
• PowerShell’i admin olarak çalıştırın ve unsigned dizilerinin çalışmasına izin verelim. (Set-ExecutionPolicy Unrestricted)

Gereksinimlerimiz hazırsa taşma işlemlerine başlayabiliriz.

İlk olarak MigAz ‘i çalıştırıyorum ve login oluyorum;

Aşağıdaki adımları gerçekleştiriyorum;

Subscriptions alanından taşıma yapacağım aboneliği seçiyorum.
Taşımak istediğim kaynakları virtual network , storage account ve sanal makinemi seçiyorum.
MigAz aracı, taşımak istediğimiz sanal makineye ait bilgileri ARM şablonuna göre düzenleyen bir JSON dosyası oluşturur.
Oluşan JSON dosyasını export edeceğim dizini gösteriyorum.

2

3

MigAz export ettiğimiz dizine 2 json dosyası çıkarır ;

• CopyBlobDetails.json: Bu dosya, ARM/CSP aboneliğine kopyalanması gereken sanal sabit disklerin ayrıntılarını içerir. Bu kaynak URI’leri ve depolama erişim anahtarlarını içerir – bu dosyaları diskleri indirmek için kullanabileceğinden dolayı güvende tutmakta var 
• Export.json: Bu dosya, diske bağlı olmayan makinelerin tüm ARM bağımlılıklarıyla yeniden dağıtımını yapmak için kullanılacak şablonu içermektedir.

Diskleri daha sonra kopyalayacağımız için CopyBlobDetails.json’a sonradan döneceğiz, biz Export.json üzerinde çalışmaya devam edelim. Bu dosyayı açarsanız, sanal makineniz için ARM’de oluşturulacak her şeyi barındırdığını göreceksiniz. Değişiklik yapmak için bu dosyayı düzenleyebilirsiniz. Belki NAT kurallarını değiştirmek veya makineler eklemek istersiniz. Bu bölümdeki her şey isteğe bağlıdır.
Bir düzenleyicinin herhangi bir yerine gitmeden önce, düzenlemeleri geri alabilmeniz ve orijinal yapılandırmaya referansınız olması için JSON dosyasını kopyalayarak düzenleme yapmanızı öneririm.

Dosyaya gözattığımda, yük dengeleyicisine dinamik bir ortak IP adresi kaynağı atanacağını görüyorum.Dışardan olabilecek erişimler ve DNS yönetimi için statik bir IP adresi istiyorum. Ayrıca, IP adresinin adını isimlendirme standartlarıma uygun olacak şekilde değiştirebilirim.

Bu doğrultuda json dosyasını açarak PublicIp adresimi Static duruma getirerek isimlendirme standardıma uygun bir isim verebilirim.Tabi bu isim değişiklik sonrasında load balancer adına bir çok referans bulunmaktadır. Bu bağımlılıkları da değiştirebilmek için notepad içinde eski isim ile yeni ismimi replace all fonksiyonu ile hızlıca değiştiebilirsiniz.

Yukarıdaki örneğe istinaden ip adresini , stroage account isimlerini ve buna benzer kaynaklarınızı da kendi planlarınız doğrultusunda düzenleyebilirsiniz.
Her taşıma işlemi için stroage account isimlendirmesi benzersiz olmalıdır. MigAz default olarak storage account adını alacak ve ARM dağıtımı için sonuna v2 ekleyecek şekilde yapılandırılacaktır.

Disk ile ilgili değişikler yapmanız durumunda CopyBlobDetails.json dosyasını da düzenlemeniz gerektiğini unutmayın. Neden buna ihtiyaç var diye düşündüğünüzü hissediyorum  .Nedeni ARM aboneliğine kopyalanma sırasında sabit disklerin bloklarının adlandırılmasına ilişkin talimatlar içeriyor olmasıdır.
Bu örneği JSON dosyamızı düzenleyebileceğimizi anlatmak ve anlamak adına verdim. Test bir VM’i taşıdığım için ve production ortamda çalışmayacağım için ben bu değişiklikleri detaylıca yapmadan sadece public ip adresimi static hale getirerek ilerleyeceğim.

Bu bilgi ve detayların ardından artık ARM Depolymentine geçebilirim ;

Öncelikle Login-AzureRMAccount ile login oluyorum.

Hesabınızın erişebildiği abonelikleri listelemek için Get-AzureRMSubscription komutunu kullanıyorum.

VM’leri dağıtmak istediğiniz aboneliğin kimliğini kopyalayın ve çalıştırın ;

4

Ardından, seçtiğimiz Azure bölgesinde yeni bir kaynak grubu oluşturmamız gerekmektedir :

5

Disklerin henüz kopyalanmadığını unutmayın, bu içe aktarımın sonunda bir sürü hata olacaktır. Hatalar, eksik sanal sabit diskleri ifade eder.
URI ile VHD blob bulunamadı
Bu hataları daha sonra çözeceğiz.

Şimdi Disklerimizin ARM aboneliğimize nasıl kopyalanacağına bakalım..

MigAz zip dosyasını export ettiğim dizine PowerShell’den ulaşıyorum. BlobCopy.ps1 adlı bir komut dosyası çalıştırıp CopyBlobDetails.json öğesine yönlendiriliyorum. Bu komut, kaynak aboneliğindeki disklerin anlık görüntüsünü oluşturacak ve diskleri (Azure ağını kullanarak) doğrudan CSP / ARM aboneliğindeki yeni depolama hesabına kopyalayacaktır.

.\BlobCopy.ps1 -ResourcegroupName “rg-mig1” -DetailsFilePath “C:\Users\Onur\Desktop\MigazVmDeployment\copyblobdetails.json” -StartType StartBlobCopy

6

Kopyalamanın hangi aşamada olduğunu ya da ilerleme durumunu izlemek için aşağıdaki komutu kullanabilirsiniz;

.\BlobCopy.ps1 -ResourcegroupName “miglabvm” -DetailsFilePath “C:\Users\Onur\Desktop\MigazVmDeployment\copyblobdetails.json” -StartType MonitorBlobCopy

7

Hatırlarsanız ilk olarak sanal makinenin geçişi için koşturduğumuz komutta disk ile ilgili hatalar almıştık. Artık diskleri ilgilendiren kısmı yukarıdaki adımda geçtiğimiz için bu hataları almamamız gerekiyor.

Bunun için komutu yeniden koşturuyorum :

New-AzureRmResourceGroupDeployment -Name migrationmigaz -ResourceGroupName miglabvm -TemplateFile “C:\Users\Onur\Desktop\MigazVmDeployment\export.json” –Verbose

8

Geçiş işlemini tamamlamış bulunuyoruz  Şimdi https://portal.azure.com adresine giderek kaynaklarımızı görüntüleyebiliriz.

Kaynaklarımı kontrol ettim ve son olarak hatırlayacağınız üzerine json template içersinde sabitlediğim ip adresimin durumunu kontrol ediyorum;

Özetleyecek olursak classic portaldan geçiş işlemlerinde desteklenen ve desteklenmeyen özelliklerin önceden planlanması ile birlikte bir çok konfigürasyon ve değişikliklerin geçiş öncesi belirlenerek bu senaryo sonrasında yapılması gereken iş akışlarının saptanması gerekmektedir. Temelde geçiş işlemi makalede anlattığım gibi sağlansa da mevcut çalışan yapıyı sekteye uğratmayacak konfigürasyonların geçiş sonrasında yapılandırılması migration senaryosunun en önemli tarafı olduğunu unutmamak gerekmektedir. Bu aşamaları migration sonrası yapılması gereken adımlar olarak adlandırabiliriz. Örneğin ; Backup Vault’un yeniden oluşturulması gibi. Bu konuyla ilgili farklı bir makaleye yer vereceğim…

MigAz supported olmamasına rağmen oldukça iyi çalışan ve GUI barındıran tek araçtır.

Deployment senaryoları ve bileşenlerle ilgili yeni yazıları zaman buldukça paylaşacağım.

Faydalı Olması Dileğiyle.

Bir cevap yazın