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 çok sayıda harika özellik sunsa da, 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, Azure Müşteri Danışmanlığı ekibi ve büyük ortamları geçirme konusunda müşterilerle birlikte çalışan Bulut Çözümü mimarları tarafından büyük katkılar sağlandı. Bu nedenle, bu belge yeni başarı desenleri ortaya çıktıkçe 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ına bağlı olarak şunları göz önünde bulundurmak isteyebilirsiniz:

  1. Azure Resource Manager kuruluşunuz için neden istenir? Geçişin iş nedenleri nelerdir?
  2. Azure Resource Manager 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. İşletim ekipleriniz artık hem Klasik hem de Azure Resource Manager 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ı nedir?
  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 olması gerekir mi? Öyleyse, ne kadar süreyle?
  9. Paydaşları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ş belge 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ılamayabilecek uygulama süresi konusunda yeterince uyarmak için yeterli arabelleği 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.

Tam senaryonuzun (işlem, ağ ve depolama) laboratuvar testini gerçekleştirmek, sorunsuz bir geçiş sağlamanın en iyi yoludur. Bu, aşağıdakilerin sağlanmasına yardımcı olur:

  • Test etmek için tamamen ayrı bir laboratuvar veya mevcut üretim dışı bir ortam. Art arda 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 silinme 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, daha büyük geçişlerin birç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şvurmanız gerekir. Bu teknik sorunlarla karşılaşabilir veya karşılaşmayabilirsiniz, ancak geçiş denemesi yapmadan önce bunları çözerseniz daha sorunsuz bir deneyim elde edebilirsiniz.

  • Doğrulama/Hazırlama/Çalıştırmayı Durdurma - Klasik'i Azure'a Resource Manager geçişin 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ğrula seçeneği 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 Validate her şeyi yakalamaz. Geçiş işleminin bir sonraki adımı olan Hazırlama, bu sorunların ortaya çıkarılacağına yardımcı olur. Hazırlama işlemi meta verileri Klasik'ten Azure Resource Manager'a taşır, ancak taşıma işlemini gerçekleştirmez ve Klasik tarafındaki hiçbir şeyi kaldırmaz veya değiştirmez. Kuru çalıştırma, geçişin hazırlanmasını ve ardından geçişlerin hazırlanmasını durdurmayı (işlemeyi değil) içerir. Kuru çalıştırmayı doğrulama/hazırlama/durdurmanın amacı, Azure Resource Manager yığınındaki tüm meta verileri görmek, incelemek (program aracılığıyla veya Portalda) ve her şeyin doğru geçirildiğini doğrulamak ve teknik sorunlarla çalışmaktır. Ayrıca, kapalı kalma süresini buna göre planlamak için 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 bağlı değildir.

    • 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 sağlamanın güvenli ve değerli bir yolu olduğunu belirledik.
    • 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çirmeye yönelik en büyük engellerden biri olabilir. VM Uzantılarının düzeltılması 1-2 gün kadar sürebilir, bu nedenle buna göre plan yapın. Çalışan VM'lerin VM Uzantısı durumunu geri raporlamak için çalışan bir Azure aracısı gerekir. Durum çalışan bir VM için kötü olarak geri gelirse, bu geçiş işlemini durdurur. Geçişi etkinleştirmek için aracının çalışması 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, geçiş hazırlanmadan önce BGInfo v1.* dışındaki tüm VM Uzantılarının her VM'den kaldırılması ve ardından Azure Resource Manager geçişinden sonra 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 olmaz.

    • 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 ile oluşturulduysa, büyük olasılıkla aracı çalışıyorsa ve giden İnternet erişimine (ve DNS'ye) sahip olması koşuluyla Azure Resource Manager geçirilebilen JSON tabanlı BGInfo 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, geçiş öncesinde tüm VM'leri kapatmak/serbest bırakmak başka bir seçenektir. 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çirileceğidir. Dezavantajı, genel kullanıma yönelik tüm Sanal IP'lerin kaybolmasıdır (bu başlangıç olmayan bir durum olabilir) ve açıkçası VM'lerin kapatılması, çalışan uygulamalar üzerinde çok daha büyük bir etkiye neden olur.

      Not

      Bulut için Microsoft Defender ilkesi geçirilen çalışan VM'lere göre 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ın (bulut hizmeti) içerdiği 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ümesi 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 değiştirmeniz 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 Cloud Services 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 expressroute bağlantı hattına da bağlı ayrı bir Klasik sanal ağa taşımak veya kodu daha yeni PaaS Uygulama Hizmetleri'ne 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şınmakta olan 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çirilemez olarak sanal ağ geçişi tamamlandıktan sonra), bu nedenle performans kaybı olmadan ve gecikme süresi/bant genişliği cezaları 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 geçişi engellenemez.

  • Azure Resource Manager Kotaları - Azure bölgeleri hem Klasik hem de Azure Resource Manager için ayrı kotalara/sınırlara sahiptir. Geçiş senaryosunda yeni donanımlar kullanılmıyor olsa da (mevcut VM'leri Klasik'ten Azure Resource Manager'ye değiştiriyoruz) azure Resource Manager kotalarının geçiş başlayabilmesi için 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ı kontrol edebilirsiniz.

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

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

      Ağ(Sanal Ağlar, 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 (örneğin>, bir VNET'te 400 VM) Azure Resource Manager yazma işlemleri için varsayılan API azaltma sınırlarına (şu anda 1200 yazma/saat) basabilirsiniz. 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'de sağlama durumu zaman aşımına uğradıysa, geçiş öncesi bu sorunun çözülmesi gerekir. Bunu gerçekleştirmenin tek yolu, VM'nin sağlamasını kaldırma/yeniden sağlamayı kaldırma (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ş durursa 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: Birkaç dakika sonra geçişi 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şturulmadığı (son hafta içinde) ve henüz Azure Resource Manager iş yükleri için donatılmış olmayan bir Azure kümesine inmesidir. Doku kümesi yok ve VM geçirilemiyor hatasını alırsınız. Küme yakında Azure Resource Manager etkinleştirileceğinden, birkaç gün beklemek genellikle bu sorunu çözer. Ancak sanal makineye yönelik geçici çözümlerden biri, geçiş işlemine stop-deallocate devam etmek ve geçiş sonrasında Azure Resource Manager vm yedeklemesini başlatmaktır.

Kaçınılması gereken tuzaklar

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

Geçiş

Teknik konular ve dezavantajlar

Ortamınızla ilgili bilinen sorunları incelediğiniz için artık hazırsı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 üretimi zamanlayın.
  3. (İSTEĞE BAĞLı) Beklenmeyen sorunlar ortaya çıkması durumunda bol miktarda arabelleğe sahip 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 geçiş öncesinde dikkate alınmalı ve azaltılmalıdır. Yeterli test ile geçiş aslında olay dışıdır. Üretim ortamları için, 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 genel bakışını okuyun.

Dikkat edilmesi gerekenler:

  • Geçişi diğer etkinliklerle paketleme. Müşterilerin çoğu uygulama bakım penceresini tercih eder. Öyleyse, ş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 için teknik ve iş nedenlerini yeniden ziyaret edin; yalnızca Ortamınız için geçerli olan Azure Resource Manager kullanılabilir ek hizmetleri etkinleştirin.
  • PaaS hizmetleriyle ortamınızı modernleştirin.

Başarı desenleri

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

Kaçınılması gereken tuzaklar

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

Sonraki adımlar