Son zamanlarda yoğun olarak uğraştığım ve uzun uğraşlar gerektiren bir konu olan Azure taşıma işlemlerini makale olarak dikkat edilmesi gereken durumları da belirtip kaleme almak istedim. Umarım herkes için faydalı ve yararlanacağı birer kaynak olurlar.

Bildiğiniz gibi Azure üzerinde farklı subscription modelleri bulunuyor. Bu modeller Azure’un satın alınma biçimine göre genelde farklılık gösterir. Bu bağlamda subscriptionlar Pay-as-you-go, Enterprise Aggrement ve CSP(Cloud Solution Pbrovider) olarak bir kaç modele ayrılır.

Tabi bu modellerdeki subscription’larda desteklenen Azure servisleri de farklılık gösterebilir ancak %95 oranında aynı servisleri barındırırlar.

İşim gereği bazı durumlarda bu subscription’lar içerisindeki resource grouplar arasında yada direk subscription’lar arasında taşıma yapmak durumunda kalabiliyoruz.

Subscription’lar arasında fiyatsal farklılıklar da bulunuyor. Bu sebeple kurumlar örneğin kendi kredi kartı ile pay-as-you-go olarak aldığı subscription’ı CSP subscription’a yada EA bir subscription’a taşımak isteyebiliyorlar.

Böyle durumlarda taşıma işlemi kolay bir işlemmiş gibi görünsede (Azure portal üzerindeki move seçeneğinden dolayı) maalesef tüm bileşenler bu şekilde move edilemiyor.

Taşınamayan bileşenlerin listesi özet olarak aşağıdaki gibidir.

• AD Domain Services
• AD Hybrid Health Service
• Application Gateway
• BizTalk Services
• Container Service
• Express Route
• DevTest Labs
• Dynamics LCS
• Load Balancers – (Standard SKU olan load balancer’lar taşınmıyor)
• Managed Applications
• Managed Disks
• Public IP – (Standard SKU olan public IP’ler taşınamıyor)
• Recovery Services vault – (Recovery Services Vault ile ilişkili Compute, Network, ve Storage kaynakları taşınamıyor)
• Security
• StorSimple Device Manager
• Virtual Networks (classic)

Taşıma işlemleri sırasında kaynak ve hedef resource group’lar yazma ve silme işlemlerine karşı kilitlenir. Taşıma tamamlandıktan sonra tekrar normale dönerler.

Taşıma işlemleri sırasında taşınan
kaynağın lokasyonu hiç bir şekilde değişmez. Resource group farklı bir lokasyonda olabilir. Ancak kaynak kesinlikle aynı lokasyonda kalacaktır.

Taşıma işlemlerini yapmadın önce yapılması gereken bir kaç check list bulunmaktadır. Bunlar sırası ile aşağıdaki gibidir;

1. Kaynak ve hedef subscription’lar aynı Active Directory tenant’ında bulunması gerekir. Bunu kontrol etmek için aşağıdaki powershell komutlarını kullanabilirsiniz. Eğer iki subscription’a ait tenant id’si aynı ise ikisi de aynı tenant’a bağlıdır.

   (Get-AzureRmSubscription -SubscriptionName <your-source-subscription>).TenantId
   

   (Get-AzureRmSubscription -SubscriptionName <your-destination-subscription>).TenantId
   

Eğer iki subscription’a ait tenant ID’leri farklı ise yapılması gereken işlem Azure subscription’ın tenant’lar arasında transfer edilmesi işlemidir. Bunun işlem için aşağıdaki kaynaklardan faydalanabilir siniz.

https://docs.microsoft.com/th-th/azure/billing/billing-subscription-transfer

https://docs.microsoft.com/th-th/azure/active-directory/active-directory-how-subscriptions-associated-directory

1. Taşınacak servislerin taşıma için desteklenip desteklenmediğinin belirlenmesi gerekir. (Yukarıda verilen listede taşınamayacak kaynaklar yer alıyor)
2. Hedef subscription’ın resource provider’a resource taşınabilir olarak register edilmesi gerekir. Eğer bu şekilde bir registration yapılmamış ise aşağıdaki hata alınacaktır.

   “subscription is not registered for a resource type” Bu durumu düzeltmek için aşağıdaki komutları sırası ile kullanmak yeterli olacaktır.

   Subscription’a ait registration durumunu öğrenmek için aşağıdaki komutu kullanabilirsiniz.

Set-AzureRmContext -Subscription <destination-subscription–name-or-id>

Get-AzureRmResourceProvider -ListAvailable | Select-Object ProviderNamespace, RegistrationState

Registration işlemi içinde komutu aşağıdaki şekildeki gibi çalıştırabilirsiniz.

Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Batch

Taşıma işlemlerinde bizim için önemli bazı kaynaklara ilişkin sınırlılıkları biraz daha ayrıntılı inceleyelim. Taşıma sırasında bu kaynaklar özelinde yapmamız gerekenlere biraz daha ayrıntılı göz atalım;

Sanal Makine Sınırlılıkları

Tabi söz konusu taşıma olduğunda en önemli bileşenlerden birisi de kuşkusuz sanal makinelerdir. Bu taşıma işlemlerinde sanal makinelerde yaşadığım en büyük sıkıntı makinenin disklerinin yönetilen disk (managed) olarak yapılandırılmış olmasıdır. Bu dumuma bağlı olarak aşağıdaki şekilde managed disk’e bağlı kaynakları taşıyamıyoruz.

• Managed disks
  
• Managed disk’e sahip sanal makineler
  
• Managed disk kullanılarak oluşturulmuş imajlar.
  
• Managed disk üzerinden oluşturulmuş snapshot’lar
  
• Managed disk’e sahip vm’ler ile oluşturulmuş availability set’ler.
  

Buna ek olarak market place üzerindeki belli kaynaklara bağlı olarak oluşturulan sanal makineler de yine taşınamayan bileşenler arasındadır.

Eğer taşınacak sanal makine key vault içerisinde bir sertifikayı kullanıyor ise, sanal makine ayrı subscription içerisinde farklı bir resource group’a taşınabilir fakat farklı subscription’a taşınamaz.

Virtual Network Sınırlılıkları

Eğer ortamda peer edilmiş virtual network’ler var ise öncelikle bu peering’in disable edilmesi gerekir. Ardından taşıma işlemi sorunsuz olrak gerçekleşecektir. Taşımanın ardından peering tekrar enable edilerek taşıma tamamlanacaktır.

Eğer virtual network içerisinde resource navigation link’e sahip bir subnet var ise taşıma yapılamaz. (Redis cache kullanılan senaryolarda rastlanır)

App Service Sınırlılıkları

Subscription içerisinde App service bulunuyor ise ve taşınacaksa bunu iki farklı senaryoda ele almak gerekir.

Eğer aynı subscription içerisinde taşıma yapılacaksa SSL sertifika taşınamaz. Yapılacak işlem sertifikanın silinip web app’in taşınması, ardından sertifikanın tekrardan upload edilmesi işlemidir.

Eğer web app farklı subscription üzerindeki bir resource group’a taşınacak ise hedef resource group aşağıdaki bileşenleri içermemelidir.

• Web App’ler
• App Service planları
• Upload eidlmiş yada import edilmiş SSL sertifika
• App Service ortamları

Ek olarak resource group içerisindeki tüm app service kaynakları birlikte taşınmalıdır. Ayrıca app service resource’ları taşınırken tüm taşınacak bileşenler orjinal olarak oluşturuldukları resource group’a taşınmalı ve bu resource group ile taşıma işlemi yapılmalıdır.

Recovery Service Sınırlılıkları

Taşıma sırasında en çok sorun yaşatan bileşenlerden birisi de recovery service bileşenidir. Çoğu zaman Azure sanal makineleri için backup yapılandırması yaptığımızda taşıma işlemleri sırasında sanal makinenin taşınamayacağına ilişkin hata alırız. Bu durumu aşmak için sırası ile aşağıdaki işlemlerin yapılması gerekir. Bu işlem aynı subscription içerisinde farklı resource grouplar arasında geçerlidir.

1. Azure backup geçici olarak durdurulup backup datası tutulmalıdır.
2. Sanal makine hedef resource group’a taşınmalıdır.
3. Aynı yada farklı vault kullanılarak sanal makine tekrardan korumaya alınmalıdır.

Eğer vm farklı subscription’lar arasında taşınacak ise ilk iki madde yine aynı olacaktır. Fakat 3. madde recovery service vault’un cross-subscription-backup desteğinin olmamasından ötürü desteklenmeyecektir.

Bu bölümde sınırlılıklardan ve bu sınırlılıkların nasıl aşılabileceğinden bahsetmiş olduk. Bir sonraki bölümde taşıma işlemleri ile devam edeceğim.

Görüşmek üzere.

Bu konuyla ilgili sorularınızı http://forum.mshowto.org linkini kullanarak ulaşacağınız forum sayfamızda sorabilirsiniz.

Referanslar

www.mshowto.org

https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-move-resources

Fırat

TAGs: Azure ARM, Azure Resource Manager Move Process, Azure ARM Move, Move Azure Resource to another subscription,Azure resource copy, Move ASM to ARM, Azure Resource Manager Powershell, Azure ARM Move limitation,ARM Infrastructure