stv1 platformunda barındırılan sanal ağa eklenmiş API Management örneğini stv2'ye geçirme

ŞUNLAR IÇIN GEÇERLIDIR: Geliştirici | Premium

Bu makalede, örnek bir dış veya iç sanal ağa eklendiğinde (dağıtıldığında) işlem platformunda stv1stv2 barındırılan bir API Management örneğini platforma geçirme adımları sağlanır. Bunu yapmanız gerekip gerekmediğini öğrenin.

Sanal ağ ekleme örneği için aşağıdaki geçiş seçenekleriniz vardır:

• Seçenek 1: Aynı alt ağı tutma - Örneği yerinde geçirin ve örneklerin mevcut alt ağ yapılandırmasını koruyun. API Management örneğinin özgün VIP adresinin korunup korunmayacağını (önerilen) veya yeni bir VIP adresi oluşturulup oluşturulmayacağını seçebilirsiniz.

• 2. Seçenek: Yeni bir alt ağa geçme - Aynı veya farklı bir sanal ağda farklı bir alt ağ belirterek örneğinizi geçirin. Geçiş sonrasında isteğe bağlı olarak örneğin özgün alt a bilgisayarına geri dönün. Geçiş işlemi, örneğin VIP adreslerini değiştirir. Geçiş sonrasında DNS, güvenlik duvarı kuralları ve sanal ağlar dahil olmak üzere tüm ağ bağımlılıklarını yeni VIP adreslerini kullanacak şekilde güncelleştirmeniz gerekir.

Belirli, daha az sıklıktaki koşullar altında, aynı alt ağda geçiş mümkün olmayabilir veya farklı davranabilir. Daha fazla bilgi için bkz . Özel koşullar ve senaryolar.

Platformda stv1 barındırılan sanal ağ eklememiş bir API Management'ı geçirmeniz gerekiyorsa bkz. Sanal ağ eklememiş API Management örneğini stv2 platformuna geçirme.

Geçiş sırasında ne olur?

api management platform geçişi stv1stv2 , temel alınan işlemi tek başına güncelleştirmeyi içerir ve depolama katmanında kalıcı olan hizmet/API yapılandırması üzerinde hiçbir etkisi yoktur.

• Yükseltme işlemi, eski işleme paralel olarak yeni bir işlem oluşturmayı içerir ve bu işlem 45 dakikaya kadar sürebilir. Çok bölgeli dağıtımlar için ve alt ağı birden çok kez değiştirmeyi içeren senaryolarda daha uzun süreler planlayın.
• Azure portalındaki API Management durumu Güncelleştiriliyor olacaktır.
• Belirli geçiş seçenekleri için VIP adresini korumayı seçebilirsiniz veya yeni bir genel VIP oluşturulur.
• Yeni bir VIP adresi oluşturulduğunda geçiş senaryoları için:
  • Geçişi Azure yönetir.
  • Özel bir etki alanı kullanılıyorsa ağ geçidi DNS'i hala eski işlemi işaret ediyor.
  • Özel DNS kullanımda değilse ağ geçidi ve portal DNS'i yeni işlemle hemen ilgilidir.
  • İç sanal ağ modundaki bir örnek için müşteri DNS'yi yönetir, bu nedenle DNS girişleri müşteri tarafından güncelleştirilene kadar eski işleme işaret etmeye devam eder.
  • Yeni veya eski işlemi işaret eden ve dolayısıyla API'lerde kapalı kalma süresi olmayan DNS'tir.
  • Varsa, yeni işlem alt ağdaki arka uçlara ulaşmasını sağlamak için güvenlik duvarı kurallarınızda değişiklikler yapılması gerekir.
  • Geçiş başarılı olduktan sonra, eski işlem kısa bir süre sonra otomatik olarak kullanımdan çıkarılır. Portaldaki Platform geçişi dikey penceresini kullanarak yeni bir alt ağa geçiş yaparken, eski ağ geçidini 48 saat boyunca tutmak için bir geçiş ayarını etkinleştirebilirsiniz. 48 saatlik gecikme seçeneği yalnızca sanal ağ eklenmiş hizmetler için kullanılabilir.

Önkoşullar

• İşlem platformunda barındırılan stv1 bir API Management örneği. Örneğinizin platformda stv1 barındırıldığını onaylamak için bkz. API Management örneğimi hangi platformun barındırdığını Nasıl yaparım? biliyor musunuz?
• Örnek şu anda bir dış veya iç sanal ağda dağıtılmalıdır.

Diğer önkoşullar, aşağıdaki bölümlerde yer alan geçiş seçeneklerine özeldir.

1. Seçenek: Aynı alt ağı geçirme ve tutma

API Management örneğinizi stv2 mevcut alt ağ yapılandırmasını koruyarak platforma geçirebilirsiniz ve bu da geçişinizi basitleştirir. Azure portalındaki Platform geçişi dikey penceresini veya Stv2 REST API'sine Geçiş'i kullanarak geçiş yapabilirsiniz.

Önkoşullar

• Her alt ağa bir ağ güvenlik grubu eklenmelidir ve platformdaki stv2 API Management için NSG kuralları yapılandırılmalıdır. En düşük bağlantı ayarları şunlardır:

  • 443 numaralı bağlantı noktası üzerinden Azure Depolama'ya giden
  • 1433 numaralı bağlantı noktası üzerinden Azure SQL'e giden
  • 443 numaralı bağlantı noktası üzerinden Azure Key Vault'a giden
  • 6390 numaralı bağlantı noktası üzerinden Azure Load Balancer'dan gelen
  • 3443 numaralı bağlantı noktası üzerinden ApiManagement hizmet etiketinden gelen
  • API Management hizmetini çağıran istemciler için 80/443 numaralı bağlantı noktası üzerinden gelen
  • Alt ağda Azure Depolama, Azure SQL ve Azure Key Vault için hizmet uç noktaları etkinleştirilmelidir

• Mevcut her alt ağın adres alanı, geçiş sırasında mevcut hizmetinizin bir kopyasını mevcut hizmetinizle yan yana barındıracak kadar büyük olmalıdır.

• Ağ ile ilgili dikkat edilmesi gereken diğer noktalar:

  • Alt ağda dağıtılan API Management örnekleri için yapılandırılmış otomatik ölçeklendirme kurallarını kapatın. Otomatik ölçeklendirme kuralları geçiş işlemini etkileyebilir.
  • Aynı alt ağda birden çok API Management örneğiniz varsa, her örneği sırayla geçirin. Aynı alt ağda farklı platformlarda barındırılan örneklerle ilgili olası sorunları önlemek için alt bilgisayarınızda bulunan tüm örnekleri hemen geçirmenizi öneririz.

• Azure Cloud Shell'de Bash ortamını kullanın. Daha fazla bilgi için bkz . Azure Cloud Shell'de Bash için hızlı başlangıç.

  

• CLI başvuru komutlarını yerel olarak çalıştırmayı tercih ediyorsanız Azure CLI'yı yükleyin . Windows veya macOS üzerinde çalışıyorsanız Azure CLI’yi bir Docker kapsayıcısında çalıştırmayı değerlendirin. Daha fazla bilgi için bkz . Docker kapsayıcısında Azure CLI'yi çalıştırma.

  • Yerel yükleme kullanıyorsanız az login komutunu kullanarak Azure CLI ile oturum açın. Kimlik doğrulama işlemini tamamlamak için terminalinizde görüntülenen adımları izleyin. Diğer oturum açma seçenekleri için bkz . Azure CLI ile oturum açma.

  • İstendiğinde, ilk kullanımda Azure CLI uzantısını yükleyin. Uzantılar hakkında daha fazla bilgi için bkz. Azure CLI ile uzantıları kullanma.

  • Yüklü sürümü ve bağımlı kitaplıkları bulmak için az version komutunu çalıştırın. En son sürüme yükseltmek için az upgrade komutunu çalıştırın.

Genel IP adresi seçenekleri - aynı alt ağ geçişi

API Management örneğinin özgün VIP adresinin korunup korunmayacağını (önerilen) veya yeni bir VIP adresi oluşturulup oluşturulmayacağını seçebilirsiniz.

• Sanal IP adresini koruma - Sanal ağdaki VIP adresini dış modda korursanız, API istekleri geçiş sırasında yanıt vermeye devam edebilir (bkz . Beklenen kapalı kalma süresi); iç modda bir sanal ağ için geçici kapalı kalma süresi beklenir. Altyapı yapılandırması (özel etki alanları, konumlar ve CA sertifikaları gibi) 45 dakika boyunca kilitlenir. Geçiş sonrasında başka yapılandırma gerekmez.

  Bu seçenekle stv1 işlem, geçiş tamamlandıktan sonra kalıcı olarak silinir. Geçici olarak saklama seçeneği yoktur.

  Aşağıdaki görüntüde, IP adresi korunduğunda neler olduğuna ilişkin üst düzey bir genel bakış gösterilmektedir.

  

• Yeni sanal IP adresi - Bu seçeneği belirlerseniz, API Management örneğiniz için yeni bir VIP adresi oluşturur. API istekleri geçiş sırasında yanıt vermeye devam eder. Altyapı yapılandırması (özel etki alanları, konumlar ve CA sertifikaları gibi) 30 dakika boyunca kilitlenir. Geçiş sonrasında, yeni VIP adresini kullanmak için DNS, güvenlik duvarı kuralları ve sanal ağlar dahil olmak üzere tüm ağ bağımlılıklarını güncelleştirmeniz gerekir.

  Bu seçenekle, stv1 geçiş tamamlandıktan sonra işlem varsayılan olarak kısa bir süre boyunca tutulur, böylece geçirilen örneği doğrulayabilir ve ağ ile DNS yapılandırmasını onaylayabilirsiniz.

  Aşağıdaki görüntüde, yeni bir IP adresi oluşturulduğunda neler olduğuna ilişkin üst düzey bir genel bakış gösterilmektedir.

  

Geçiş için önceden oluşturulmuş IP adresi

Genel IP adresiyle ulaşılabilen API Management örnekleri için API Management, geçiş işlemi için bir genel IP adresi oluşturur. API Management örneğinizin özelliklerinin JSON çıkışında önceden oluşturulmuş IP adresini bulun. altında customProperties, önceden oluşturulmuş IP adresi özelliğinin Microsoft.WindowsAzure.ApiManagement.Stv2MigrationPreCreatedIps değeridir. Çok bölgeli dağıtım için değer, önceden oluşturulmuş IP adreslerinin virgülle ayrılmış bir listesidir.

Geçiş işlemini yönetmenize yardımcı olması için önceden oluşturulmuş IP adresini (veya adreslerini) kullanın:

• VIP adresini geçirip koruduğunuzda, özgün IP adresi dağıtıma atanmadan önce önceden oluşturulmuş IP adresi geçici olarak yeni stv2 dağıtıma stv2 atanır. Örneğin API Management örneğine erişimi sınırlayan güvenlik duvarı kurallarınız varsa, geçiş sırasında istemci erişiminin sürekliliğini korumak için önceden oluşturulmuş IP adresini izin verilenler listesine ekleyebilirsiniz. Geçiş tamamlandıktan sonra, önceden oluşturulmuş IP adresini izin verilenler listenizden kaldırabilirsiniz.
• Yeni bir VIP adresi geçirip oluşturduğunuzda, önceden oluşturulmuş IP adresi geçiş sırasında yeni stv2 dağıtıma atanır ve geçiş tamamlandıktan sonra da devam eder. DNS ve güvenlik duvarı kuralları gibi ağ bağımlılıklarınızı yeni IP adresine işaret etmek üzere güncelleştirmek için önceden oluşturulmuş IP adresini kullanın.

Beklenen kapalı kalma süresi ve işlem saklama

Sanal ağ eklenmiş bir örneği geçirirken ve aynı alt ağ yapılandırmasını tutarken, API ağ geçidi için en düşük kapalı kalma süresi beklenir. Aşağıdaki tabloda, aynı alt ağı tutarken her geçiş senaryosu için beklenen kapalı kalma süresi ve stv1 işlem saklama işlemi özetlenmektedir:

Geçiş adımları - aynı alt ağı tutma

APIM_NAME={name of your API Management instance}
# In PowerShell, use the following syntax: $APIM_NAME={name of your API Management instance}
RG_NAME={name of your resource group}
# Get resource ID of API Management instance
APIM_RESOURCE_ID=$(az apim show --name $APIM_NAME --resource-group $RG_NAME --query id --output tsv)
# Call REST API to migrate to stv2 and preserve VIP address
az rest --method post --uri "$APIM_RESOURCE_ID/migrateToStv2?api-version=2023-03-01-preview" --body '{"mode": "PreserveIp"}'
# Alternate call to migrate to stv2 and change VIP address
# az rest --method post --uri "$APIM_RESOURCE_ID/migrateToStv2?api-version=2023-03-01-preview" --body '{"mode": "NewIp"}'

2. Seçenek: Geçiş ve yeni alt ağa geçme

Azure portalını kullanarak, aynı veya farklı bir sanal ağda farklı bir alt ağ belirterek örneğinizi geçirebilirsiniz. Geçiş sonrasında isteğe bağlı olarak örneğin özgün alt a bilgisayarına geri dönün.

Aşağıdaki görüntüde, yeni bir alt ağa geçiş sırasında neler olduğuyla ilgili üst düzey bir genel bakış gösterilmektedir.

Önkoşullar

• API Management örneğinin dağıtıldığı her bölgede geçerli sanal ağda yeni bir alt ağ. (Alternatif olarak, API Management örneğiniz ile aynı bölgelerde ve abonelikte farklı bir sanal ağda bir alt ağ ayarlayın). Her alt ağa bir ağ güvenlik grubu eklenmelidir ve platformdaki stv2 API Management için NSG kuralları yapılandırılmalıdır.

• (İsteğe bağlı) API Management örneğiniz ile aynı bölgelerde ve abonelikte yeni bir Standart SKU genel IPv4 adres kaynağı. Ayrıntılar için bkz . Ağ bağlantıları için önkoşullar.

Geçiş adımları - yeni bir alt ağa geçiş

1. Azure portalında API Management örneğine gidin.

2. Soldaki menüde, Ayarlar'ın altında Platform geçişi'ni seçin.

3. Geçiş seçeneği belirleyin altında Yeni alt ağa değiştir'i seçin.

4. Gereksinimlerinize uygun senaryoyu seçin altında, özgün stv1 işlemi geçiş sonrasında bir süre boyunca korumak isteyip istemediğinize bağlı olarak iki seçenek arasında seçim yapın.

   

5. Her konum için geçiş ayarlarını tanımla altında:

   1. Geçiş için bir konum seçin.
   2. Geçirmek istediğiniz Sanal ağı, Alt ağı ve isteğe bağlı Genel IP adresini seçin.

   

6. Alt ağınızın geçiş gereksinimlerini karşıladığını doğrulayın bölümünde Doğrula'yı seçerek alt ağda otomatik denetimler çalıştırın. Sorun algılanırsa alt ağ yapılandırmanızı ayarlayın ve denetimleri yeniden çalıştırın. DNS ve güvenlik duvarı kuralları gibi diğer ağ bağımlılıkları için el ile denetleyin.

7. Geçirmek istediğinizi onaylayın ve Geçir'i seçin. API Management örneğinizin durumu Güncelleştiriliyor olarak değişir. Geçiş işleminin tamamlanması yaklaşık 45 dakika sürer. Durum Çevrimiçi olarak değiştiğinde geçiş tamamlanır.

API Management örneğiniz birden çok bölgeye dağıtıldıysa, örneğinizin kalan konumları için sanal ağ ayarlarını geçirmeye devam etmek için önceki adımları yineleyin.

(İsteğe bağlı) Özgün alt ağa geri geçiş

Geçiş yapıp yeni bir alt ağa değiştirdiyseniz, isteğe bağlı olarak her bölgede kullandığınız özgün alt ağa geri geçiş yapın. Bunu yapmak için, bu kez her bölgedeki özgün sanal ağı ve alt ağı belirterek sanal ağ yapılandırmasını yeniden güncelleştirin. Önceki geçişte olduğu gibi, uzun süre çalışan bir işlem ve VIP adresinin değişmesini bekleyebilirsiniz.

Aşağıdaki görüntüde, özgün alt ağa geri geçiş sırasında neler olduğuyla ilgili üst düzey bir genel bakış gösterilmektedir.

Ek önkoşullar

• API Management örneğinin dağıtıldığı her bölgede kilidi açılmış özgün alt ağ. Alt ağa bir ağ güvenlik grubu eklenmelidir ve API Management için NSG kuralları yapılandırılmalıdır.

• (İsteğe bağlı) API Management örneğiniz ile aynı bölgelerde ve abonelikte yeni bir Standart SKU genel IPv4 adres kaynağı.

  Önemli

  • Mayıs 2024'den itibaren, bir API Management örneğini iç modda bir sanal ağa dağıtırken (eklerken) veya iç sanal ağ yapılandırmasını yeni bir alt ağa geçirirken genel IP adresi kaynağına ihtiyaç duyulmaz . Dış sanal ağ modunda genel IP adresi belirtmek isteğe bağlıdır; sağlamazsanız Azure tarafından yönetilen genel IP adresi otomatik olarak yapılandırılır ve çalışma zamanı API'si trafiği için kullanılır. Genel IP adresini yalnızca İnternet'e gelen veya giden iletişim için kullanılan genel IP adresine sahip olmak ve denetlemek istiyorsanız sağlayın.

Sanal ağ yapılandırmasını güncelleştirme

1. Portalda özgün sanal ağınıza gidin.
2. Sol menüde Alt ağlar'ı ve ardından özgün alt ağı seçin.
3. Özgün IP adreslerinin API Management tarafından yayımlandığını doğrulayın. Kullanılabilir IP'lerin altında alt ağda kullanılabilen IP adreslerinin sayısını not edin. Tüm adresler (Azure ayrılmış adresleri hariç) kullanılabilir olmalıdır. Gerekirse, IP adreslerinin serbest bırakılabilmesini bekleyin.
4. API Management örneğine gidin.
5. Soldaki menüde, Ağ'ın altında Sanal ağ'ı seçin.
6. Güncelleştirmek istediğiniz konumdaki ağ bağlantısını seçin.
7. Özgün sanal ağ ağını ve alt ağı seçin. İsteğe bağlı olarak yeni bir genel IP seçin. Uygula’yı seçin.
8. API Management örneğiniz birden çok bölgede dağıtıldıysa örneğinizin kalan konumları için sanal ağ ayarlarını yapılandırmaya devam edin.
9. Üst gezinti çubuğunda Kaydet'i seçin.

Sanal ağ yapılandırmasını güncelleştirdikten sonra API Management örneğinizin durumu Güncelleştiriliyor olarak değişir. Geçiş işleminin tamamlanması yaklaşık 45 dakika sürer. Durum Çevrimiçi olarak değiştiğinde geçiş tamamlanır.

Geçişi doğrulama

Geçişin başarılı olduğunu doğrulamak için durum Çevrimiçi olarak değiştiğinde API Management örneğinizin platform sürümünü denetleyin. Geçiş başarılı olduktan sonra değeri veya stv2.1şeklindedirstv2.

Eski ağ geçidi temizlenmeden önce ayarları onaylayın

Geçiş sonrasında eski ağ geçidinin geçici olarak korunduğunu senaryolarda, geçiş sırasında oluşturulan eski ve yeni işlem, dağıtımı doğrulamak için kullanabileceğiniz ve uygulamalarınızın beklendiği gibi çalıştığı kısa bir süre (yaklaşık 15 dakika) bir arada bulunur. Belirli senaryolarda, bir portal ayarı aracılığıyla bekletme süresini isteğe bağlı olarak 48 saate uzatabilirsiniz.

• Bu pencere sırasında, eski ve yeni ağ geçitleri hem çevrimiçidir hem de trafiğe hizmet eder. Bu süre boyunca faturalandırılmazsınız.
• DNS, güvenlik duvarı kuralları ve sanal ağlar dahil olmak üzere tüm ağ bağımlılıklarını yeni VIP adresi ve alt ağ adres alanını kullanacak şekilde güncelleştirmek için bu pencereyi kullanın.
• Ayrıca, güncelleştirilmiş örneğin ağ durumunu denetleerek örneğin bağımlılıklarına bağlandığından emin olun. Portalda, sol taraftaki menüde, Dağıtım ve altyapı'nın altında Ağ>Ağı durumu'nu seçin. Gerekirse UDR'ler ve NSG kuralları gibi ayarları güncelleştirin.
• Pencereden sonra eski ağ geçidi kullanımdan çıkarılır ve trafiğe hizmet veren tek ağ geçidi yeni ağ geçidi olur.

Geçiş başarısız olursa otomatik olarak geri dön

Geçiş işlemi sırasında bir hata oluşursa örnek otomatik olarak platforma stv1 geri döner. Geçiş başarıyla tamamlanırsa (örneğin platform sürümü veya stv2.1 olarak ve durumu Çevrimiçi olarak stv2gösterilir), platforma stv1 geri dönemezsiniz.

Geçiş başarısız olursa yardım için Azure desteği başvurun.

El ile geri alma özelliğine ihtiyacınız varsa, özgün API Management örneğinizle yan yana yeni stv2 bir örnek dağıtmanız önerilir.

Özel koşullar ve senaryolar

Belirli koşullar altında, Seçenek 1: Aynı alt ağı geçirme ve tutma kullanılabilir olmayabilir veya farklı davranabilir. Portal bu koşulları algılar ve geçiş seçeneğini önerir. Seçenek 1'i kullanamıyorsanız veya birden çok koşul varsa, Seçenek 2: Yeni bir alt ağa geçin seçeneğini kullanın.

• Özel iç koşullara sahip sanal ağ - API Management örneğiniz şu anda özel iç koşullara (müşteri yapılandırmasıyla ilgili olmayan) sahip bir sanal ağda dağıtılıyorsa portalda, portalda aynı alt ağ geçişi için Seçenek 1'in ek kapalı kalma süresi (yaklaşık 1 saat) içerdiği bildirilir. Geçiş için portalın kullanılması önerilir. Yaklaşık 1 saatlik kapalı kalma süresiyle aynı alt ağ geçişi için aşağıdaki değiştirilmiş Azure CLI betiğini de kullanabilirsiniz:

  APIM_NAME={name of your API Management instance}
  # In PowerShell, use the following syntax: $APIM_NAME={name of your API Management instance}
  RG_NAME={name of your resource group} 
  # Get resource ID of API Management instance
  APIM_RESOURCE_ID=$(az apim show --name $APIM_NAME --resource-group $RG_NAME --query id --output tsv)
  # Call REST API to migrate to stv2 and preserve VIP address for special condition
  az rest --method post --uri "$APIM_RESOURCE_ID/migrateToStv2?api-version=2024-06-01-preview&migrateWithDowntime=true" --body '{"mode": "PreserveIP"}' 
  

• Alt ağda birden çok stv1 örneği - Örnekleri aynı anda geçirmeyi denerseniz aynı alt ağ geçişi için yeterli boş IP adresleri kullanılamayabilir. 1. Seçeneği kullanarak örnekleri sıralı olarak geçirebilirsiniz.

• Alt ağ temsilcisi - API Management'ın dağıtıldığı alt ağ şu anda diğer Azure hizmetlerine devrediliyorsa, Seçenek 2'yi kullanarak geçirmeniz gerekir.

• Azure Key Vault engellendi - Azure Key Vault'a erişim şu anda engellenmişse, Azure Key Vault'a erişim için yeni alt ağda NSG kurallarını ayarlama da dahil olmak üzere Seçenek 2'yi kullanarak geçirmeniz gerekir.

Otomatik geçiş

Kullanımdan kaldırma tarihinden sonra kalan stv1 hizmet örneklerini otomatik olarak işlem platformuna stv2 geçireceğiz. Etkilenen tüm müşterilere bir hafta önceden yaklaşan otomatik geçiş bildirilir. Otomatik geçiş, yukarı akış API'nizin tüketicileri için kapalı kalma süresine neden olabilir. Otomatik geçiş gerçekleşmeden önce kendi örneklerinizi geçirmeye devam edebilirsiniz.

Sanal ağ yapılandırması otomatik geçiş sırasında kaldırılabilir

Çoğu durumda otomatik geçiş, yapılandırılmışsa API Management örneğinizin sanal ağ ayarlarını korur. Belirli özel koşullar altında, otomatik geçiş sırasında hizmet örneğinizin stv1 sanal ağ yapılandırması kaldırılır ve güvenlik önlemi olarak hizmet uç noktalarınıza erişim engellenir. Geçiş işlemi sırasında ağ ayarları kaldırıldıysa portalda şuna benzer bir ileti görürsünüz: We have blocked access to all endpoints for your service.

Erişim engellenmiş olsa da API ağ geçidine, geliştirici portalına, doğrudan yönetim API'sine ve Git deposuna erişim devre dışı bırakılır. Hizmet uç noktalarınıza erişimi geri yüklemek için:

1. API Management örneğinizi sanal ağınızda yeniden dağıtarak. Adımlar için API Management'ı bir dış veya iç sanal ağda dağıtma kılavuzuna bakın. Örneği, API Management stv2 işlem platformuyla uyumlu ayarlarla sanal ağın yeni bir alt ağına dağıtmanızı kesinlikle öneririz.
2. Sanal ağ yeniden yüklendikten sonra hizmet uç noktalarınıza erişimin engelini kaldırın. Portalda, örneğin Genel Bakış sayfasında Hizmetimin engelini kaldır'ı seçin. Bu eylem geri alınamaz.

Yardım ve destek

Hizmetlerinizde en az kesintiyle platforma stv2 geçmenize yardımcı olmak için buradayız.

Sorularınız varsa Microsoft Soru-Cevap'taki topluluk uzmanlarından hızlı yanıtlar alın. Destek planınız varsa ve teknik yardım almak istiyorsanız destek isteği oluşturun.

1. Özet için sorununuzun açıklamasını yazın; örneğin, "stv1 kullanımdan kaldırma".
2. Sorun türü'nin altında Teknik'i seçin.
3. Abonelik bölümünde aboneliğinizi seçin.
4. Hizmet'in altında Hizmetlerim'i ve ardından API Management Hizmeti'ne tıklayın.
5. Kaynak'ın altında, destek isteği oluşturmakta olduğunuz Azure kaynağını seçin.
6. Sorun türü için Yönetim ve Yönetim'i seçin.
7. Sorun alt türü için Yükselt, Ölçek veya SKU Değişiklikleri'ne tıklayın.

Sık sorulan sorular

• Geçiş yolu seçmek için hangi bilgilere ihtiyacımız var?

  • API Management örneğinin ağ modu nedir?
  • Özel etki alanları yapılandırıldı mı?
  • Güvenlik duvarı söz konusu mu?
  • İlgili IP'lerde yukarı/aşağı akış tarafından alınan bilinen bağımlılıklar var mı?
  • Çok bölgeli bir dağıtım mı?
  • Mevcut örneği değiştirebilir miyiz yoksa paralel kurulum gerekli mi?
  • Kapalı kalma süresi olabilir mi?
  • Geçiş, iş dışı saatlerde yapılabilir mi?

• Geçiş için önkoşullar nelerdir?

  Sanal ağa eklenen örnekler için, aynı alt ağı geçirme ve koruma ya da yeni bir alt ağa geçiş ve geçiş seçeneklerinin önkoşullarına bakın.

• Geçiş kapalı kalma süresine neden olacak mı?

  Sanal ağ eklenmiş bir örneği geçirirken ve aynı alt ağ yapılandırmasını tutarken, API ağ geçidi için en düşük kapalı kalma süresi beklenir. Beklenen kapalı kalma süresi bölümündeki özet tabloya bakın.

  Yeni bir VIP adresine geçiş ve değiştirme sırasında varsayılan konak adları kullanılıyorsa kapalı kalma süresi olmamalıdır. Etkilenen API'lerin işlevsel olması için tüm ağ bağımlılıklarının önceden ele alınması kritik önem taşır. Ancak özel etki alanları kullanımdaysa, güncelleştirilene kadar temizlenen işlemi işaret eder ve bu da kapalı kalma süresine neden olabilir. Alternatif olarak, belirli geçiş seçenekleri için, eski ağ geçidini 48 saat boyunca korumak için bir geçiş ayarını etkinleştirin. Eski ve yeni işlem birlikte bulunması doğrulamayı kolaylaştırır ve ardından özel DNS girişlerini istediğiniz zaman güncelleştirebilirsiniz.

• Trafiğim bir güvenlik duvarı üzerinden zorla tünelleniyor. Hangi değişiklikler gereklidir?

  • Her şeyden önce, geçiş için kullandığınız alt ağların aşağıdaki yapılandırmayı koruduğundan emin olun (geçerli alt ağınızı geçiriyor ve koruyorsanız bunlar zaten yapılandırılmış olmalıdır):
    • Hizmet uç noktalarını burada açıklandığı gibi etkinleştirin
    • UDR'de (kullanıcı tanımlı yol) ApiManagement hizmet etiketinden atlama "İnternet" olarak ayarlanmış ve yalnızca güvenlik duvarı adresinize ayarlanmamıştır
  • Güvenlik duvarınız olsun veya olmasın, stv2 için NSG yapılandırması gereksinimleri aynı kalır; yeni alt ağınızda olduğundan emin olun
  • API Management örneğinin geçerli IP adresi aralığına başvuran güvenlik duvarı kuralları, yeni alt ağınızın IP adresi aralığını kullanacak şekilde güncelleştirilmelidir.

• Veri veya yapılandırma kayıpları geçiş sırasında gerçekleşebilir mi?

  stv1 geçiş işlemi stv2 yalnızca işlem platformunun güncelleştirilmesini içerir ve iç depolama katmanı değiştirilmez. Bu nedenle, geçiş işlemi sırasında tüm yapılandırmalar güvenlidir. Bu, sistem tarafından atanan yönetilen kimliği içerir ve bu kimlik etkinleştirilirse korunur.

• Geçişin tamamlandığını ve başarılı olduğunu onaylama

  Genel Bakış sayfasındaki durum Veya olan platform sürümüyle stv2.1stv2 birlikte Çevrimiçi olarak okunduğunda geçişin tamamlanmış ve başarılı olduğu kabul edilir. Ayrıca Ağ dikey penceresindeki ağ durumunun gerekli tüm bağlantılar için yeşil görüntülendiğini doğrulayın.

• Geçişi portalı kullanarak yapabilir miyim?

  Evet, sanal ağa eklenen örnekler Platform geçişi dikey penceresi kullanılarak geçirilebilir.

• Örneğin IP adresini koruyabilir miyim?

  Evet, portaldaki Platform geçişi dikey penceresinde ve REST API'de IP adresini koruma seçenekleri vardır.

• Mevcut örneği değiştirmeden bir geçiş yolu var mı?

  Evet, yan yana geçiş yapmanız gerekir. Bu, geçerli örneğiniz ile paralel olarak yeni bir API Management örneği oluşturacağınız ve yapılandırmayı yeni örneğe kopyaladığınız anlamına gelir.

• Geçiş başarısız olursa ne olur?

  API Management örneğiniz, geçişi başlattıktan sonra platform sürümünü veya stv2.1 durumunu Çevrimiçi olarak stv2göstermiyorsa, büyük olasılıkla başarısız olmuştur. Hizmetiniz otomatik olarak eski örneğe geri alınır ve hiçbir değişiklik yapılmaz.

• Geçiş sırasında hangi işlevler kullanılamaz?

  API istekleri geçiş sırasında yanıt vermeye devam eder. Altyapı yapılandırması (özel etki alanları, konumlar ve CA sertifikaları gibi) 30 dakika boyunca kilitlenir.

• Geçiş ne kadar sürer?

  Yeni bir sanal ağ yapılandırmasına geçiş için beklenen süre yaklaşık 45 dakikadır. Geçişin zaten gerçekleştirilip gerçekleştirilmediğini denetleme göstergesi, Örneğinizin Durumunun Güncelleştiriliyor değil Çevrimiçi olup olmadığını denetlemektir. Çok bölgeli dağıtımlar için ve alt ağı birden çok kez değiştirmeyi içeren senaryolarda daha uzun süreler planlayın.

• Geçiş denemeden önce sanal ağ yapılandırmasını doğrulamanın bir yolu var mı?

  Geçiş sırasında alt ağı değiştirmeyi planlıyorsanız, gerçek geçiş için kullanacağınız sanal ağ, alt ağ ve (isteğe bağlı) IP adresi kaynağıyla yeni bir API Management örneği dağıtabilirsiniz. Dağıtım tamamlandıktan sonra Ağ durumu sayfasına gidin ve her uç nokta bağlantı durumunun yeşil olup olmadığını doğrulayın. Evet ise, bu yeni API Management örneğini kaldırabilir ve özgün stv1barındırılan hizmetinizle gerçek geçişe devam edebilirsiniz.

• Gerekirse geçişi geri alabilir miyim?

  Geçiş işlemi sırasında bir hata oluşursa örnek otomatik olarak platforma stv1 geri döner. Ancak hizmet başarıyla geçirildikten sonra platforma stv1 geri dönemezsiniz.

• Özel etki alanı/özel DNS bölgelerinde herhangi bir değişiklik gerekli mi?

  İç modda sanal ağ eklenmiş örnekler ve yeni bir VIP'ye geçtiğinizde, özel DNS bölgelerini geçiş sonrasında alınan yeni sanal ağ IP adresine güncelleştirmeniz gerekir. Azure dışı DNS bölgelerini de güncelleştirmeye dikkat edin (örneğin, API Management özel IP adresine işaret eden şirket içi DNS sunucularınız). Ancak, dış modda geçiş işlemi kullanımdaysa varsayılan etki alanlarını otomatik olarak güncelleştirir.

• Stv1 örneğim birden çok Azure bölgesine (çok bölgeli) dağıtıldı. stv2'ye yükseltme Nasıl yaparım??

  Çok bölgeli dağıtımlar, diğer konumlara dağıtılan daha fazla yönetilen ağ geçidi içerir. Portalda Platform geçişi dikey penceresini kullanarak geçiş yaptığınızda, her konumu ayrı olarak geçirirsiniz. Stv2 REST API'sine Geçiş, tüm konumları tek bir çağrıda geçirir. Örnek, yalnızca tüm konumlar geçirildiğinde yeni platforma geçirilir. Tüm bölgesel ağ geçitleri, geçiş işlemi boyunca normal şekilde çalışmaya devam eder.

• Stv1 örneğimi aynı alt ağa yükseltebilir miyim?

  Evet, portalda Platform geçişi dikey penceresini veya stv2 REST API'sine geçir'i kullanın.

• Canlı trafiği değiştirmeden önce yeni ağ geçidini yeni bir alt ağda test edebilir miyim?

  • Yeni bir alt ağa geçiş yaptığınızda, eski ve yeni yönetilen ağ geçitleri varsayılan olarak 15 dakika boyunca bir arada bulunur ve bu, dağıtımı doğrulamak için küçük bir zaman aralığıdır. Eski ağ geçidini 48 saat boyunca korumak için bir geçiş ayarını etkinleştirebilirsiniz. Bu değişiklik, trafiği almak ve doğrulamayı kolaylaştırmak için eski ve yeni yönetilen ağ geçitlerini etkin tutar.
  • Geçiş işlemi varsayılan etki alanı adlarını otomatik olarak güncelleştirir ve kullanılıyorsa trafik yeni ağ geçitlerine hemen yönlendirilir.
  • Özel etki alanı adları kullanılıyorsa, CNAME kullanılmıyorsa ilgili DNS kayıtlarının yeni IP adresiyle güncelleştirilmesi gerekebilir. Müşteriler konak dosyalarını yeni API Management IP'sine güncelleştirebilir ve anahtarı yapmadan önce örneği doğrulayabilir. Bu doğrulama işlemi sırasında eski ağ geçidi canlı trafiğe hizmet etmeye devam eder.

• Yeni bir alt ağda varsayılan etki alanı adı kullanılırken dikkat edilmesi gereken noktalar var mı?

  Dış modda varsayılan DNS adını kullanan örnekler, DNS'nin geçiş işlemi tarafından otomatik olarak güncelleştirilmiş olmasıdır. Ayrıca, her zaman varsayılan etki alanı adını kullanan yönetim uç noktası, geçiş işlemi tarafından otomatik olarak güncelleştirilir. Geçiş başarılı bir geçişte hemen gerçekleştiğinden, yeni örnek trafiği hemen almaya başlar ve etkilenen API'lerin kullanılamamasını önlemek için ağ kısıtlamaları/bağımlılıklarının önceden ele alınması kritik önem taşır.

• Şirket içinde barındırılan ağ geçitleri için neleri dikkate almalıyız?

  Şirket içinde barındırılan ağ geçitlerinizde herhangi bir işlem yapmanız gerekmez. Yalnızca Azure'da çalışan ve platformun kullanımdan kaldırılmasından etkilenen stv1 API Management örneklerini geçirmeniz yeterlidir. API Management örneğinin Yapılandırma uç noktası için yeni bir IP olabileceğini ve IP'ye sabitlenen ağ kısıtlamalarının güncelleştirilmesi gerektiğini unutmayın.

• Geliştirici portalı geçiş işlemini nasıl etkiler?

  Geliştirici portalı üzerinde herhangi bir etkisi yoktur. Özel etki alanları kullanılıyorsa, DNS kaydı geçiş sonrasında geçerli IP ile güncelleştirilmelidir. Ancak, varsayılan etki alanları kullanımdaysa, başarılı geçişte otomatik olarak güncelleştirilir. Geçiş sırasında geliştirici portalı için kapalı kalma süresi yoktur.

• Stv2'ye geçiş yaptıktan sonra maliyet üzerinde herhangi bir etki var mı?

  Faturalama modeli için stv2 aynı kalır ve geçiş sırasında ve sonrasında daha fazla maliyet oluşmaz.

• stv1'in stv2 geçişi için hangi RBAC izinleri gereklidir?

  Geçiş işleminin kullanıcı/işlem için API Management örneğine yazma erişimi olması gerekir. Ayrıca, aşağıdaki iki izin gereklidir:

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/publicIPAddresses/join/action

İlgili içerik

• API Management örneğimi hangi platformun barındırdığını nasıl bilebilirim?

• API Management için stv2 işlem platformunun avantajları

• stv1 platform kullanımdan kaldırma - küresel Azure (Ağustos 2024)

• stv1 platform kullanımdan kaldırma - 21Vianet tarafından sağlanan Azure Kamu ve Azure (Şubat 2025)