IaaS kaynaklarının Klasik’ten Azure Resource Manager’a geçişini planlama

  • Makale

Şunlar için geçerlidir: ✔️ Linux VM'leri ✔️ Windows VM'leri

Önemli

Günümüzde IaaS VM'lerinin yaklaşık %90'ı Azure Resource Manager kullanıyor. 28 Şubat 2020 itibarıyla klasik VM'ler kullanımdan kaldırılmıştır ve 6 Eylül 2023'te tamamen kullanımdan kaldırılacaktır. Bu kullanımdan kaldırma ve bunun sizi nasıl etkilediği hakkında daha fazla bilgi edinin.

Azure Resource Manager birçok harika özellik sunarken, işlerin sorunsuz bir şekilde ilerlemesini sağlamak için geçiş yolculuğunuzu planlamak kritik önem taşır. Planlamaya zaman harcamak, geçiş etkinliklerini yürütürken sorunlarla karşılaşmamanızı sağlar.

Not

Aşağıdaki kılavuz, Büyük ortamları geçirme konusunda müşterilerle birlikte çalışan Azure Müşteri Danışmanlığı ekibi ve Bulut Çözümü mimarları tarafından büyük ölçüde katkıda bulunmuştur. Bu nedenle, yeni başarı desenleri ortaya çıktıkçe bu belge güncelleştirilmeye devam edecektir, bu nedenle yeni öneriler olup olmadığını görmek için zaman zaman tekrar kontrol edin.

Geçiş yolculuğunun dört genel aşaması vardır:

Geçiş aşamaları

Planlama

Teknik konular ve dezavantajlar

Teknik gereksinimlerinizin boyutuna, coğrafyalarına ve operasyonel uygulamalarınıza bağlı olarak şunları göz önünde bulundurmak isteyebilirsiniz:

  1. Kuruluşunuz için Azure Resource Manager neden istenir? Geçişin iş nedenleri nelerdir?
  2. Azure Resource Manager'ın teknik nedenleri nelerdir? Başka hangi Azure hizmetlerini (varsa) kullanmak istersiniz?
  3. Geçişe hangi uygulama (veya sanal makine kümeleri) dahil edilir?
  4. Geçiş API'sinde hangi senaryolar desteklenir? Desteklenmeyen özellikleri ve yapılandırmaları gözden geçirin.
  5. Operasyonel ekipleriniz artık hem Klasik hem de Azure Resource Manager'daki uygulamaları/VM'leri destekleyecek mi?
  6. Azure Resource Manager VM dağıtım, yönetim, izleme ve raporlama işlemlerinizi nasıl değiştirir ?... Dağıtım betiklerinizin güncelleştirilmiş olması gerekiyor mu?
  7. Paydaşları (son kullanıcılar, uygulama sahipleri ve altyapı sahipleri) uyarmak için iletişim planı nelerdir?
  8. Ortamın karmaşıklık düzeyine bağlı olarak, uygulamanın son kullanıcılar ve uygulama sahipleri tarafından kullanılamadığı bir bakım dönemi olmalıdır? Öyleyse ne kadar süreyle kullanmıştı?
  9. Proje katılımcılarının Azure Resource Manager'da bilgili ve yetkin olmasını sağlamaya yönelik eğitim planı nedir?
  10. Geçiş için program yönetimi veya proje yönetimi planı nedir?
  11. Azure Resource Manager geçişi ve diğer ilgili teknoloji yol haritaları için zaman çizelgeleri nelerdir? En uygun şekilde hizalanmışlar mı?

Başarı desenleri

Başarılı müşteriler, önceki soruların tartışıldığı, belgelendiği ve yönetildiği ayrıntılı planlara sahiptir. Geçiş planlarının sponsorlara ve paydaşlara geniş bir şekilde iletildiğinden emin olun. Geçiş seçenekleriniz hakkında bilgi sahibi olun; aşağıdaki geçiş belgesi kümesinde okuma yapmak kesinlikle önerilir.

Kaçınılması gereken tuzaklar

  • Plan başarısız oldu. Bu geçişin teknoloji adımları kanıtlanmıştır ve sonuç tahmin edilebilirdir.
  • Platform tarafından desteklenen geçiş API'sinin tüm senaryoları hesaba aktaracağı varsayımı. Hangi senaryoların desteklendiğini anlamak için desteklenmeyen özellikleri ve yapılandırmaları okuyun.
  • Son kullanıcılar için olası uygulama kesintisi planlanmaması. Son kullanıcıları kullanılamama olasılığı olan uygulama süresi konusunda yeterince uyarmak için yeterli arabellek planlayın.

Laboratuvar Testi

Ortamınızı çoğaltma ve test geçişi yapma

Not

Mevcut ortamınızın tam çoğaltması, Microsoft Desteği tarafından resmi olarak desteklenmeyen topluluk tarafından katkıda bulunan bir araç kullanılarak yürütülür. Bu nedenle, isteğe bağlı bir adımdır, ancak üretim ortamlarınıza dokunmadan sorunları bulmanın en iyi yoludur. Topluluk tarafından katkıda bulunan bir araç kullanmak bir seçenek değilse aşağıdaki Doğrulama/Hazırlama/Durdurma Kuru Çalıştırma önerisi hakkında bilgi edinin.

Sorunsuz bir geçiş sağlamanın en iyi yolu, tam senaryonuz (işlem, ağ ve depolama) için laboratuvar testi gerçekleştirmektir. Bu, aşağıdakilerin sağlanmasına yardımcı olur:

  • Test etmek için laboratuvarı veya mevcut üretim dışı ortamı tamamen ayırın. Tekrar tekrar geçirilebilen ve yıkıcı bir şekilde değiştirilebilen tamamen ayrı bir laboratuvar öneririz. Gerçek aboneliklerden meta verileri toplamak/nemlendirmek için betikler aşağıda listelenmiştir.

  • Laboratuvarı ayrı bir abonelikte oluşturmak iyi bir fikirdir. Bunun nedeni laboratuvarın tekrar tekrar yıkılması ve ayrı, yalıtılmış bir aboneliğe sahip olmanın gerçek bir şeyin yanlışlıkla silinmesi olasılığını azaltmasıdır.

    Bu, AsmMetadataParser aracı kullanılarak gerçekleştirilebilir. Bu araç hakkında daha fazla bilgiyi burada bulabilirsiniz

Başarı desenleri

Aşağıda, büyük geçişlerin çoğunda bulunan sorunlar yer alır. Bu kapsamlı bir liste değildir ve daha fazla ayrıntı için desteklenmeyen özelliklere ve yapılandırmalara başvurmalısınız. Bu teknik sorunlarla karşılaşabilir veya karşılaşamayabilirsiniz, ancak geçiş denemeden önce bunları çözerseniz daha sorunsuz bir deneyim elde edebilirsiniz.

  • Bir Doğrulama/Hazırlama/Yeniden Çalıştırmayı Durdurma - Klasik'i Azure Resource Manager'a geçirmenin başarılı olmasını sağlamak için belki de en önemli adım budur. Geçiş API'sinin üç ana adımı vardır: Doğrulama, Hazırlama ve İşleme. Doğrulama, klasik ortamınızın durumunu okur ve tüm sorunların sonucunu döndürür. Ancak Azure Resource Manager yığınında bazı sorunlar olabileceğinden Doğrula her şeyi yakalamaz. Geçiş işleminin bir sonraki adımı olan Hazırlama, bu sorunların ortaya çıkarılmasına yardımcı olacaktır. Hazırlama, meta verileri Klasik'ten Azure Resource Manager'a taşır, ancak taşımayı işlemez ve Klasik tarafındaki hiçbir şeyi kaldırmaz veya değiştirmez. Kuru çalıştırma, geçişin hazırlanmasını, ardından geçişlerin hazırlanmasını durdurmayı (işlemeyi değil) içerir. Kuru çalıştırmayı doğrulama/hazırlama/durdurma hedefi, Azure Resource Manager yığınındaki tüm meta verileri görmek, incelemek (program aracılığıyla veya Portalda) ve her şeyin doğru şekilde geçirildiğini doğrulamak ve teknik sorunlarla çalışmaktır. Ayrıca, kapalı kalma süresini buna göre planlayabileceğiniz geçiş süresi hakkında fikir verir. Doğrulama/hazırlama/durdurma işlemi kullanıcının kapalı kalma süresine neden olmaz; bu nedenle, uygulama kullanımına bozulmaz.

    • Aşağıdaki öğelerin kuru çalıştırmadan önce çözülmesi gerekir, ancak bir kuru çalıştırma testi de kaçırılırsa bu hazırlık adımlarını güvenli bir şekilde temizler. Kurumsal geçiş sırasında, geçişe hazır olma durumunu güvence altına almak için kuru çalıştırmanın güvenli ve değerli bir yol olduğunu bulduk.
    • Hazırlama çalışırken, denetim düzlemi (Azure yönetim işlemleri) tüm sanal ağ için kilitlenir, bu nedenle doğrulama/hazırlama/durdurma sırasında VM meta verilerinde değişiklik yapılamaz. Ancak aksi takdirde herhangi bir uygulama işlevi (RD, VM kullanımı vb.) etkilenmez. VM'lerin kullanıcıları, kuru çalıştırmanın yürütüldüğünü bilmez.

  • Express Route Devreleri ve VPN. Şu anda yetkilendirme bağlantıları olan Express Route Ağ Geçitleri kapalı kalma süresi olmadan geçirilemiyor. Geçici çözüm için bkz . ExpressRoute bağlantı hatlarını ve ilişkili sanal ağları klasikten Resource Manager dağıtım modeline geçirme.

  • VM Uzantıları - Sanal Makine uzantıları, çalışan VM'leri geçirmenin en büyük engellerinden biridir. VM Uzantılarının düzeltilmesi 1-2 gün kadar sürebilir, bu nedenle buna göre plan yapın. Çalışan VM'lerin VM Uzantısı durumunu raporlamak için çalışan bir Azure aracısı gereklidir. Durum çalışan bir VM için kötü geri gelirse, bu geçişi durdurur. Geçişi etkinleştirmek için aracının çalışma düzeninde olması gerekmez, ancak VM'de uzantılar varsa, geçişin ilerlemesi için hem çalışan bir aracı hem de giden İnternet bağlantısı (DNS ile) gerekir.

    • Geçiş sırasında bir DNS sunucusuna bağlantı kesilirse, BGInfo v1.* dışındaki tüm VM Uzantılarının geçişe hazırlanmadan önce her VM'den kaldırılması ve ardından Azure Resource Manager geçişi sonrasında vm'ye yeniden eklenmesi gerekir. Bu yalnızca çalışan VM'ler içindir. VM'lerin serbest bırakılması durdurulursa, VM Uzantılarının kaldırılması gerekmez. Not: Azure tanılama ve Bulut için Defender izleme gibi birçok uzantı geçiş sonrasında kendilerini yeniden yükler, bu nedenle bunları kaldırmak sorun oluşturmaz.

    • Ayrıca, Ağ Güvenlik Gruplarının giden İnternet erişimini kısıtlamadığından emin olun. Bu, bazı Ağ Güvenlik Grupları yapılandırmalarında oluşabilir. VM Uzantılarının Azure Resource Manager'a geçirilmesi için giden İnternet erişimi (ve DNS) gerekir.

    • BGInfo uzantısının iki sürümü vardır: v1 ve v2. VM, Azure portalı veya PowerShell kullanılarak oluşturulduysa büyük olasılıkla vm üzerinde v1 uzantısına sahip olacaktır. Bu uzantının kaldırılması gerekmez ve geçiş API'si tarafından atlanır (geçirilmez). Ancak, Klasik VM yeni Azure portalıyla oluşturulduysa büyük olasılıkla aracı çalışıyor ve giden İnternet erişimine (ve DNS) sahip olması koşuluyla Azure Resource Manager'a geçirilebilen BGInfo'nun JSON tabanlı v2 sürümüne sahip olacaktır.

    • Düzeltme Seçeneği 1. VM'lerinizin giden İnternet erişimine, çalışan bir DNS hizmetine ve VM'lerde çalışan Azure aracılarına sahip olmadığını biliyorsanız, Hazırlamadan önce geçişin bir parçası olarak tüm VM uzantılarını kaldırın ve geçişten sonra VM Uzantılarını yeniden yükleyin.

    • Düzeltme Seçeneği 2. VM uzantıları çok büyük bir engelse, bir diğer seçenek de geçiş öncesinde tüm VM'leri kapatmak/serbest bırakmaktır. Serbest bırakılmış VM'leri geçirin, ardından Azure Resource Manager tarafında yeniden başlatın. Buradaki avantaj, VM uzantılarının geçirilecek olmasıdır. Bunun dezavantajı, genel kullanıma yönelik tüm Sanal IP'lerin kaybolmasıdır (bu başlangıç olmayan bir işlem olabilir) ve açıkçası VM'lerin kapatılması, çalışan uygulamalar üzerinde çok daha büyük bir etkiye neden olur.

      Not

      Geçirilen çalışan VM'lere karşı bir Bulut için Microsoft Defender ilkesi yapılandırılırsa, uzantıları kaldırmadan önce güvenlik ilkesinin durdurulması gerekir, aksi takdirde güvenlik izleme uzantısı kaldırıldıktan sonra vm'ye otomatik olarak yeniden yüklenir.

  • Kullanılabilirlik Kümeleri - Bir sanal ağın (vNet) Azure Resource Manager'a geçirilmesi için, klasik dağıtım (bulut hizmeti gibi) içeren VM'lerin tümünün tek bir kullanılabilirlik kümesinde olması veya VM'lerin tümünün herhangi bir kullanılabilirlik kümesinde olmaması gerekir. Bulut hizmetinde birden fazla kullanılabilirlik kümesinin olması Azure Resource Manager ile uyumlu değildir ve geçişi durdurur. Ayrıca, kullanılabilirlik kümesinde bazı VM'ler ve kullanılabilirlik kümesinde olmayan bazı VM'ler olamaz. Bu sorunu çözmek için bulut hizmetinizi düzeltmeniz veya yeniden dağıtmanız gerekir. Zaman alıcı olabileceği için buna göre plan yapın.

  • Web/Çalışan Rolü Dağıtımları - Web ve çalışan rollerini içeren Bulut Hizmetleri Azure Resource Manager'a geçiremez. Geçişin başlayabilmesi için önce web/çalışan rollerinin sanal ağdan kaldırılması gerekir. Tipik bir çözüm, web/çalışan rolü örneklerini aynı zamanda ExpressRoute bağlantı hattına bağlı ayrı bir Klasik sanal ağa taşımak veya kodu daha yeni PaaS App Services'e geçirmektir (bu tartışma bu belgenin kapsamı dışındadır). Eski yeniden dağıtım örneğinde yeni bir Klasik sanal ağ oluşturun, web/çalışan rollerini bu yeni sanal ağa taşıyın/yeniden dağıtın, ardından dağıtımları taşınan sanal ağdan silin. Kod değişikliği gerekmez. Yeni Sanal Ağ Eşleme özelliği, geçirilmekte olan sanal ağ gibi aynı Azure bölgesindeki web/çalışan rollerini ve diğer sanal ağları içeren klasik sanal ağı eşlemek için kullanılabilir (eşlenmiş sanal ağlar geçirilemediği için sanal ağ geçişi tamamlandıktan sonra), bu nedenle performans kaybı ve gecikme süresi/bant genişliği cezası olmadan aynı özellikleri sağlar. Sanal Ağ Eşlemesi'nin eklenmesiyle, web/çalışan rolü dağıtımları artık kolayca azaltılabilir ve Azure Resource Manager'a geçişi engellemez.

  • Azure Resource Manager Kotaları - Azure bölgelerinin hem Klasik hem de Azure Resource Manager için ayrı kotaları/sınırları vardır. Geçiş senaryosunda yeni donanım kullanılmıyor olsa da (mevcut VM'leri Klasik vm'den Azure Resource Manager'a değiştiriyoruz), geçişin başlayabilmesi için Azure Resource Manager kotalarının yeterli kapasiteye sahip olması gerekir. Aşağıda sorunlara neden olan başlıca sınırlar listelenmiştir. Sınırları artırmak için bir kota destek bileti açın.

    Not

    Bu sınırların geçirilecek geçerli ortamınızla aynı bölgede yükseltilmesi gerekir.

    • Ağ Arabirimleri

    • Yük Dengeleyiciler

    • Genel IP'ler

    • Statik Genel IP'ler

    • Çekirdekler

    • Ağ Güvenlik Grupları

    • Yönlendirme Tabloları

      Azure CLI'nın en son sürümüyle aşağıdaki komutları kullanarak geçerli Azure Resource Manager kotalarınızı de kontrol edebilirsiniz.

      İşlem (Çekirdekler, Kullanılabilirlik Kümeleri)

      az vm list-usage -l <azure-region> -o jsonc

      Ağ (Sanal Ağ, Statik Genel IP'ler, Genel IP'ler, Ağ Güvenlik Grupları, Ağ Arabirimleri, Yük Dengeleyiciler, Yol Tabloları)

      az network list-usages -l <azure-region> -o jsonc

      Depolama (Depolama Hesabı)

      az storage account show-usage

  • Azure Resource Manager API azaltma sınırları - Yeterince büyük bir ortamınız varsa (sanal ağda 400 VM gibi > ), Azure Resource Manager'da yazma işlemleri (şu anda 1200 yazma/saat) için varsayılan API azaltma sınırlarına ulaşabilirsiniz. Geçişe başlamadan önce, aboneliğinizin bu sınırını artırmak için bir destek bileti oluşturmanız gerekir.

  • Sağlama Zaman Aşımına Uğradı VM Durumu - Herhangi bir VM sağlamanın durumu zaman aşımına uğradıysa, bunun geçiş öncesi olarak çözülmesi gerekir. Bunu gerçekleştirmenin tek yolu VM'nin sağlamasını kaldırarak/yeniden sağlamayı kaldırarak (silme, diski tutma ve VM'yi yeniden oluşturma) kapalı kalma süresidir.

  • RoleStateUnknown VM Durumu - Rol durumu bilinmeyen bir hata iletisi nedeniyle geçiş durdurulduysa portalı kullanarak VM'yi inceleyin ve çalıştığından emin olun. Bu hata genellikle birkaç dakika sonra kendiliğinden gider (düzeltme gerekmez) ve genellikle sanal makine başlatma, durdurma, yeniden başlatma işlemleri sırasında görülen geçici bir türdür. Önerilen uygulama: Geçişi birkaç dakika sonra yeniden deneyin.

  • Doku Kümesi yok - Bazı durumlarda, bazı VM'ler çeşitli garip nedenlerle geçirilemiyor. Bu bilinen durumlardan biri, VM'nin kısa süre önce oluşturulup oluşturulmaması (geçen hafta veya daha sonra) ve henüz Azure Resource Manager iş yükleri için hazır olmayan bir Azure kümesine inmesidir. Doku kümesinin mevcut olmadığını ve VM'nin geçirilemediğini belirten bir hata alırsınız. Küme yakında Azure Resource Manager'ı etkinleştireceği için birkaç gün beklemek genellikle bu sorunu çözer. Ancak vm için geçici çözümlerden biri, geçiş işlemine stop-deallocate devam etmek ve geçiş sonrasında Azure Resource Manager'da VM yedeklemesini başlatmaktır.

Kaçınılması gereken tuzaklar

  • Kısayolları almayın ve doğrulama/hazırlama/durdurma geçişlerini atlayın.
  • Olası sorunlarınızın tümü değilse çoğu doğrulama/hazırlama/durdurma adımları sırasında ortaya çıkar.

Geçiş

Teknik konular ve dezavantajlar

Artık hazırsınız çünkü ortamınızla ilgili bilinen sorunlar üzerinde çalıştınız.

Gerçek geçişler için şunları göz önünde bulundurmak isteyebilirsiniz:

  1. Artan öncelikle sanal ağı (en küçük geçiş birimi) planlayın ve zamanlayın. Önce basit sanal ağları yapın ve daha karmaşık sanal ağlarla ilerleyin.
  2. Çoğu müşterinin üretim dışı ve üretim ortamları olacaktır. En son üretim zamanlayın.
  3. (İSTEĞE BAĞLı) Beklenmeyen sorunlar ortaya çıkması durumunda bol miktarda arabellek içeren bir bakım kapalı kalma süresi zamanlayın.
  4. Sorun çıkması durumunda destek ekiplerinizle iletişim kurun ve ekiplerinizle uyumlu olun.

Başarı desenleri

Yukarıdaki Laboratuvar Testi bölümünde yer alan teknik yönergeler, gerçek bir geçişten önce dikkate alınmalı ve azaltılmalıdır. Yeterli test ile geçiş aslında olay dışıdır. Üretim ortamlarında, güvenilir bir Microsoft iş ortağı veya Microsoft Premier hizmetleri gibi ek desteğe sahip olmak yararlı olabilir.

Kaçınılması gereken tuzaklar

Tam olarak test edilmemesi, geçişte sorunlara ve gecikmeye neden olabilir.

Geçişin Ötesinde

Teknik konular ve dezavantajlar

Artık Azure Resource Manager'da olduğunuz için platformu en üst düzeye çıkarın. Ek avantajlar hakkında bilgi edinmek için Azure Resource Manager'a genel bakış bölümünü okuyun.

Dikkat edilmesi gerekenler:

  • Geçişi diğer etkinliklerle paketleme. Müşterilerin çoğu uygulama bakım penceresini tercih eder. Bu durumda, şifreleme ve Yönetilen Diskler geçiş gibi diğer Azure Resource Manager özelliklerini etkinleştirmek için bu kapalı kalma süresini kullanmak isteyebilirsiniz.
  • Azure Resource Manager'ın teknik ve iş nedenlerini yeniden ziyaret edin; yalnızca Ortamınız için geçerli olan Azure Resource Manager'da kullanılabilen ek hizmetleri etkinleştirin.
  • PaaS hizmetleriyle ortamınızı modernleştirin.

Başarı desenleri

Azure Resource Manager'da etkinleştirmek istediğiniz hizmetler konusunda dikkatli olun. Birçok müşteri azure ortamları için aşağıdaki cazip özellikleri bulur:

Kaçınılması gereken tuzaklar

Bu Klasik'i Azure Resource Manager'a geçiş yolculuğuna neden başlattığınızı unutmayın. asıl iş nedenleri nelerdi? İş nedenini elde ettiniz mi?

Sonraki adımlar