Azure Front Door ve alternatif giriş çözümlerini kullanmak için yüksek kullanılabilirlik uygulama kılavuzu

Azure Front Door, hem dış müşteriler hem de Microsoft'un iç özellikleri için olağanüstü dayanıklılık ve kullanılabilirlik sağlamak üzere tasarlanmıştır. Azure Front Door mimarisi çoğu üretim iş yükünün gereksinimlerini karşılıyor veya aşıyor olsa da, hiçbir dağıtılmış sistemin hataya karşı bağışıklığı yoktur.

Bu makalede, Azure Front Door hizmet kesintileri sırasında Azure Front Door'dan alternatif bir içerik teslim ağına (CDN) veya Azure Application Gateway web uygulaması güvenlik duvarına (WAF) el ile yük devretmeyi etkinleştirmek için Azure Traffic Manager'ı uygulamaya yönelik üst düzey, adım adım yönergeler sağlanmaktadır. Görev açısından kritik web uygulamaları için Genel yönlendirme yedekliliği yönergelerini tamamlar.

CDN ve web uygulaması mimarilerinde yüksek kullanılabilirlik (HA) elde etmek için sektörde birden çok strateji vardır. Bu makalede özetlenen yaklaşım, basit ve elle yapılan bir "acil durum" yük devretme düzenine odaklanır. Müşteriler, kesinti sırasında trafiği hızla yeniden yönlendirmek ve hizmet durumu onaylandıktan sonra yönlendirmeyi sorunsuz bir şekilde Azure Front Door'a geri yüklemek için bu düzeni kullanabilir.

Makale ayrıca üretim ortamlarında HA desenleri uygulama, sistem durumu izleme oluşturma ve devam eden hazırlığı desteklemek için operasyonel runbook'lar oluşturma yönergelerini içerir.

Önemli operasyonel farklar

Bu kılavuzda, otomatik yük devretme sağlamak için Traffic Manager kullanan iki kanıtlanmış mimari sunulmaktadır. Aşağıdaki tabloda dikkate alınması gereken önemli operasyonel farklılıklar özetlemektedir:

Görünüş	Senaryo 1 (Azure Front Door + Application Gateway)	Senaryo 2 (Azure Front Door + diğer CDN)
Arıza durumunda yönlendirme hedefi	İkincil Traffic Manager örneği ve birden çok Application Gateway örneği.	Tek bir diğer CDN uç noktası.
Yük devretme sırasında önbelleğe alma	Hayır. Application Gateway önbelleğe almaz.	Evet.
Coğrafi dağıtım	İki belirli Azure bölgesi.	Diğer CDN'nin genel uç ağı.
WAF koruması	Azure Web Uygulaması Güvenlik Duvarı (tutarlı kural kümeleri).	Diğer CDN'nin WAF'leri (farklı kural kümeleri).
Bekleme sırasında maliyet	Sabit hesaplama maliyetleri. Application Gateway boşta olsa bile ücretlendirilir: en az kapasiteye sahip WAF_v2 için yaklaşık 200-400 USD/ay.	CDN satıcısının fiyatlandırması bağımlıdır.

Üretim ortamları için dikkat edilmesi gerekenler

Üretim iş yükleri için HA mimarileri uygularken aşağıdaki en iyi yöntemleri ve önemli notları göz önünde bulundurun:

• Birincil Traffic Manager örneğini otomatik yük devretme için yapılandırmayın.

  Azure Traffic Manager sistem durumu yoklamaları yalnızca ABD tabanlı Azure bölgelerinden kaynaklanır. Azure Front Door uç noktalarının yoklamaları (veya herhangi bir yayın yönlendirmesi kullanarak herhangi bir CDN) için bu ABD tabanlı yoklamalar neredeyse her zaman ABD POP sunucularına ulaşır ve ABD dışı POP sunucularının sistem durumunu doğrulanmamış olarak bırakır. Bu durum Traffic Manager'ın Azure Front Door ile Azure Front Door gibi herhangi bir yayın CDN'sinin gerçek genel durumuna bağlı olarak başka bir giriş hizmeti arasında otomatik olarak yük devretme yapmasını engeller.

  Birden fazla coğrafyadan sağlık doğrulaması gerektiren küresel iş yükleri için, ağırlıklı yönlendirme ve izlemenin devre dışı bırakıldığı el ile yük devretme, otomatik sağlık tabanlı yönlendirmeye göre daha güvenilir kontrol sağlar.

• Şu anda Azure Front Door tarafından yönetilen sertifikalar kullanıyorsanız kendi sertifikalarınızı getirme (BYO) sertifikalarına geçmeniz gerekir. Kendi sertifikanızı kullanarak, trafiğin izlediği giriş yolundan bağımsız olarak TLS sertifikalarını tutarlı tutabilirsiniz.

  TLS sertifikalarınızın Azure Front Door ile uyumlu olduğundan emin olun. Daha fazla bilgi için bkz. Azure Front Door özel etki alanında HTTPS yapılandırma ve Azure Front Door ile TLS şifrelemesi.

• Yük devretme yordamlarını her zaman önce üretim dışı ortamlarda test edin.

• Traffic Manager, DNS bölgesi zirvesinde (kök etki alanı) CNAME düzleştirmeyi desteklemez. Apex'te Traffic Manager gerekiyorsa, diğer ad kayıtlarını veya benzer mekanizmaları destekleyen DNS sağlayıcılarını kullanmanız gerekir. Azure DNS , böyle bir DNS sağlayıcısıdır.

• 300-600 saniyelik kısa DNS yaşam süresi (TTL) değerlerini kullanın. DNS TTL yayma sürelerini izleyin.

• Ağ güvenlik grupları (NSG) ve erişim denetim listeleri (ACL) ile Application Gateway'i kilitleyin. Gerekli platform aralıklarına ve gelen uygulama bağlantı noktalarına izin verin. Tüm giriş yolları için çıkış noktalarının güvenliğini sağlayın. Daha fazla bilgi için bkz . Ağ güvenlik grupları.

  Application Gateway WAF, HTTP/L7 saldırılarını azaltsa da, NSG'ler yalnızca paket filtreleme sağlar ve birim düzeyinde veya protokol düzeyinde (L3/L4) DDoS saldırılarına karşı koruma sağlamaz. Tüm Azure genel uç noktaları, Azure platformunda temel, her zaman açık DDoS korumasından yararlanıyor. Azure altyapısının korunmasına yardımcı olur ancak iş yüküne özgü ayarlama, telemetri, maliyet koruması veya kullanılabilirlik garantilerini içermez.

  Üretim ve görev açısından kritik iş yükleri için, Application Gateway genel IP'lerinin korunmasına yardımcı olmak için Azure DDoS Koruması hizmetini kullanmayı göz önünde bulundurun. Daha fazla bilgi için bkz. Azure DDoS Koruması fiyatlandırması.

• Azure Front Door ve yük devretme çözümleri arasındaki WAF kuralı farklarını belgele.

• Alternatif CDN platformları, Azure Front Door'da Özel Bağlantı tümleştirmesi tarafından korunan kaynaklara erişemediği için bu HA mimarileri için Azure Özel Bağlantı'nın kullanılması önerilmez.

  Ayrıca Application Gateway, özel kaynaklara ulaşmak için ek sanal ağ ve özel uç nokta yapılandırması gerektirir. Application Gateway, Azure Front Door'un yerel Özel Bağlantı özelliklerini kullanamaz.

  Azure Front Door'un diğer CDN sağlayıcılarıyla birlikte kullanıldığı üretim ortamlarında, Özel Bağlantı veya X‑Azure‑FDID doğrulama kullanamıyorsanız kaynak güvenini zorlamak için alternatif, CDN bağımsız kaynak güvenlik kontrollerini kullanmayı göz önünde bulundurun. Bu denetimler belirteç tabanlı kaynak kimlik doğrulaması (HMAC veya imzalı URL'ler), karşılıklı TLS (mTLS), özel kaynak üst bilgileri ve IP adresi filtrelemeyi içerebilir.

• Bu kılavuzda listelenen örnek komutları, otomasyon ve runbook'lar için ortamınıza uyarlanmış olacak şekilde düzenleyin.

• Açık işletim kılavuzları oluşturun. Yük devretme ve yeniden çalışma yordamlarını test edin.

• Tüm uç noktalar için kapsamlı izleme ve uyarı yapılandırma.

• Alternatif giriş çözümlerine yük devretme sırasında işlevselliğin doğruluğunu kontrol edin.

• Tüm platformlarda sertifika yenileme işlemlerini test edin.

• Yük devretme uç noktalarının işlevsel kaldığını düzenli olarak doğrulayın. Üç aylık test yapmanızı öneririz.

• Bu kılavuzda PowerShell'den çalıştırdığınız Azure CLI örnek komutları kullanılmaktadır.

• Devam etmeden önce görev açısından kritik web uygulamaları için Genel yönlendirme yedekliliğini gözden geçirin.

Senaryo 1: Traffic Manager'ın Azure Front Door'dan Application Gateway WAF'ye yük devretmesi

Bu DNS tabanlı yük dengeleme çözümü birden çok Azure Traffic Manager profili kullanır. Azure Front Door ile ilgili olası bir kullanılabilirlik sorunu durumunda Traffic Manager, Application Gateway WAF üzerinden trafiği yeniden yönlendirir. Birincil Traffic Manager örneği, Azure Front Door (birincil) ile çok bölgeli Application Gateway örneklerine işaret eden iç içe yerleştirilmiş ikincil Traffic Manager örneği arasındaki trafiği yönlendirir. Azure Front Door kesintisi sırasında trafik, WAF korumasına sahip bölgesel Application Gateway dağıtımlarına manuel olarak devredilir.

• Trafik akışı (normal işlem): Kullanıcı → DNS sorgusu → birincil Traffic Manager örneği (ağırlıklı/her zaman hizmet yönlendirme) → Azure Front Door (öncelik 1) → kaynak sunucuları.

• Trafik akışı (Azure Front Door hatası): Kullanıcı → DNS sorgusu → birincil Traffic Manager örneği (ağırlıklı/her zaman hizmet yönlendirme) → ikincil Traffic Manager örneği (öncelik modu) → Application Gateway → kaynak sunucuları.

Dağıtım öncesi: Azure Front Door ile Application Gateway karşılaştırması

Application Gateway WAF'nin sunmadığı özellikleri kullanıyorsanız, Azure Front Door ile Application Gateway WAF arasındaki özellik farklarını anlamak önemlidir. Aşağıdaki tablolarda bir genel bakış sağlanır.

Önemli

Bu çözüm, şu anda birden çok bölgede veya genel olarak trafiğe hizmet vermek için Azure Front Door kullandığınızı varsayar. Bu tasarımda, aşağıdaki adımlarda birincil Traffic Manager örneği ile bölgesel Application Gateway örnekleri arasında performans yönlendirmesi ile yapılandırılmış ikincil bir Traffic Manager örneği tanıtılır.

Azure Front Door genel bir Katman 7 hizmeti olduğundan bu yaklaşım gereklidir. İkincil Traffic Manager örneği, genel yük dengeleme katmanı olarak davranarak Azure Front Door'daki genel gecikme süresi tabanlı yönlendirmenin yerini etkili bir şekilde alır. Sonuç olarak Traffic Manager, coğrafi olarak dağıtılmış bir hedef kitle için gecikme süresi için iyileştirilmiş kullanıcı yönlendirmesini korur.

Bu mimari değişikliği göz önünde bulundurarak, en iyi performansı ve dayanıklılığı sağlamak için genel trafik desenlerini değerlendirmeniz ve anlamlı kullanıcı hacmine sahip bölgelerde Application Gateway örnekleri dağıtmanız gerekir.

Özellik farkları

Özellik	Azure Ön Kapı	Application Gateway
Temel mimari ve özellikler
Hizmet kapsamı	Genel hizmet	Bölgesel hizmet
OSI katmanı	Katman 7 (uygulama katmanı)	Katman 7 (uygulama katmanı)
Yük dengeleme düzeyi	Bölgeler arasında	Bir bölge veya sanal ağ içinde
Dağıtım modeli	Tek genel örnek	Bölge başına örnekler
Arka uç kapsamı	Herhangi bir genel uç nokta (Azure veya dış) ve seçili Özel Bağlantı uç noktaları	Sanal ağdaki tüm genel uç nokta (Azure veya dış), özel IP adresleri ve Kubernetes podları
İçerik kenarını önbelleğe alma	Yes	Hayı
Ağ mimarisi	Microsoft'un anycast ile küresel uç ağı	Azure bölgesel dağıtımı (anycast olmadan)
Yapılandırma farklılıkları
Yol paterni sözdizimi	/path/* veya tam /path	Regex desenleri, yol haritaları
WAF kural kümeleri	Varsayılan kural kümesi (OWASP), bot yöneticisi kural kümesi, HTTP DDoS kural kümesi	Varsayılan kural kümesi (OWASP), bot yöneticisi kural kümesi, HTTP DDoS kural kümesi
Sağlık probu değerlendirmesi	Yönlendirme için gecikme süresi + sistem durumu	Yalnızca sağlık durumu
Arka plan seçimi	Öncelik, ağırlık, gecikme süresine göre	Döner sistem, çerez bağlılığı
Yönlendirme kuralları
Yol tabanlı yönlendirme	✓ Evet	✓ Evet
Desen eşleştirme	Tam eşleşme yolları, joker karakter yolları (/*), büyük/küçük harfe duyarsız, joker karakter öncesinde / olmalıdır	URL yol eşlemeleri, yol tabanlı kurallar, desteklenen regex desenleri
Konak tabanlı yönlendirme	✓ Birden çok ön yüz sunucusu	✓ Çok siteli barındırma
URL rewrite	Statik yola statik yol (klasik)	URL yolu yeniden yazma
Yönlendirme yöntemleri	Öncelik, ağırlık ve gecikme süresine dayalı	Gecikme optimizasyonu, ağırlıklı dağıtım ve oturum bağlılığı için yüke duyarlı (*Kapsayıcılar için Application Gateway ile kullanılabilir)
Yönlendirme özellikleri
Kural altyapısı/yeniden yazma kuralları	Koşullar ve eylemler içeren kural kümeleri	Kural kümelerini koşullar ve eylemlerle yeniden yazma
Yol desenlerinde regex	Eşleşme desenlerinde desteklenmez	PCRE ile desteklenir
Başlık ve istek düzenleme
Üst bilgiyi yeniden yazma	✓ İstek ve yanıt üst bilgileri	✓ İstek ve yanıt üst bilgileri
Header değeri karakter sınırı	Belgelenmiş sınır yok	Yeniden yazma kurallarında 1.000 karakter
Ana bilgisayar üst bilgisini yeniden yazma	✓ Destekleniyor	✓ Desteklenir (dış etki alanlarına yeniden yazılamaz)
Sunucu değişkenleri	✓ Destekleniyor	✓ Destekleniyor
Başlık deseni eşleştirme	Desenli koşullar	Regex desen eşleştirmesi
Güvenlik özellikleri
WAF kullanılabilirliği	✓ İsteğe bağlı (Premium katman)	✓ İsteğe bağlı (WAF katmanı)
L3/4 DDoS koruması	✓ Yerleşik	Azure DDoS Koruması hizmeti aracılığıyla
SSL/TLS ilkeleri	✓ Yapılandırılabilir	✓ Yapılandırılabilir
Uçtan uca SSL	✓ Destekleniyor	✓ Destekleniyor
Özel Bağlantı desteği	✓ Premium katman	✓ V2 katmanı
WAF özel kuralları	✓ Destekleniyor	✓ Destekleniyor

WAF farklılıkları

Azure Ön Kapı	Application Gateway
Microsoft Varsayılan Kural Kümesi (DRS) 2.1	OWASP Çekirdek Kural Kümesi (CRS) 3.2 veya 4.0
Kural Kimlikleri: 949xxx serisi	Kural Kimlikleri: 9xxxxx serisi
Azure Front Door WAF (DRS): İlk 128 KB istek gövdesini inceler	Application Gateway WAF (CRS 3.2+): 2 MB'a kadar inceleme; 4 GB dosya yükleme; zorlama ve denetleme bağımsız olarak yapılandırılabilir

Recommendations

• Her WAF için ayrı kural kümeleri tutmanız gerektiğinden, temeliniz olarak Azure Front Door kural kümesini kullanın. Azure Front Door kural kümesiyle mümkün olduğunca yakından eşleşen bir Application Gateway kural kümesi oluşturun.

• Application Gateway WAF'yi ayrı ve bağımsız olarak test edin.

• Her iki platform için de tüm özel dışlamaları belgele.

• Tutarlılığı sağlamak için kural kümelerini düzenli olarak denetleyin.

• Azure Application Gateway altyapı yapılandırmasındaki ağ yönergelerine uyun. Aşağıdaki sanal ağ ve alt ağ gereksinimlerini karşıladığınızdan emin olun:

  • Aşağıdaki alt ağ boyutlandırmasını (bölge başına) kullanın:

    • Minimum: /27 (32 adresler)

    • Önerilen: Otomatik ölçeklendirme ve kesintisiz bakım için /24 (256 adres) ağ

    • Formül: (en fazla örnek sayısı için * 10) + 5 Azure ayrılmış IP adresi

    • Örnek: en fazla 20 örnek → (20 * 10) + 5 = 205 IP → /24

  • En iyi güvenlik için Application Gateway için ayrılmış bir alt ağ kullanın (başka kaynak yok).

  • Gelen bağlantının aşağıdakilere izin verdiğinden emin olun:

    • İnternet'ten (veya belirli kaynak aralıklarından) 443/80

    • Azure Gateway Manager'dan 65200-5535 (Application Gateway v2)

    • Azure Yük Dengeleyici

  • Diğer gelen bağlantıları engelleyin. Gerekli giden İnternet bağlantılarını engellemeyin.

  • Arka uç segmentasyonu ve en az ayrıcalık kuralları için uygulama güvenlik gruplarını kullanın.

Kapasite planlama ve otomatik ölçeklendirme stratejisi için bkz. Azure Application Gateway v2 için mimarinin en iyi yöntemleri.

Önemli uygulama adımları

1. Adım: Önkoşulları sağlama

• Özel bir etki alanı ve BYO sertifikasıyla yapılandırılmış Azure Front Door.

• CNAME kaydınız için daha düşük bir DNS TTL değeri, Azure Front Door'un trafiği en düşük zaman ayarına sunmasını sağlar.

• Sanal ağlar, Application Gateway örneği ve Traffic Manager örneği oluşturma izinlerine sahip Azure aboneliği.

• Azure Key Vault'ta SSL/TLS sertifikası veya yükleme için mevcut.

• Azure sanal ağlarından erişilebilen kaynak sunucular.

Önemli

Şu anda Azure Front Door tarafından yönetilen sertifikalar kullanıyorsanız, bu çözümü uygulamadan önce BYO sertifikalarına geçmeniz gerekir. Azure Front Door tarafından yönetilen sertifikalar dışarı aktarılamaz ve alternatif CDN'lere yüklenemez. Daha fazla bilgi için bkz. Azure Front Door özel etki alanında HTTPS yapılandırma.

2. Adım: Application Gateway'i ilk bölgeye dağıtma

1. Application Gateway için bir ağ altyapısı oluşturun. Daha fazla bilgi için bkz . Application Gateway altyapı yapılandırması.

2. Yönetilen kimlik oluşturun ve Key Vault erişimi verin. Daha fazla bilgi için bkz. Key Vault sertifikalarıyla TLS sonlandırma.

   Application Gateway, özel anahtarla PFX biçiminde SSL/TLS sertifikası gerektirir. Sertifika, ya Key Vault'tan erişilebilir olmalı ya da doğrudan yüklenmelidir. Tutarlı TLS davranışı sağlamak için Azure Front Door'un kullandığı sertifikayı kullanın.

3. WAF ilkesi oluştur. Daha fazla bilgi için bkz. Application Gateway için WAF ilkeleri oluşturma.

4. HTTPS ve WAF ile bir Application Gateway örneği oluşturun. Daha fazla bilgi için TLS sonlandırma ile bir Application Gateway örneğini yapılandırma bölümüne bakın.

5. Arka uç ana bilgisayar header'ını yapılandırın. Daha fazla bilgi için bkz. Application Gateway'de arka uç sistem durumu sorunlarını giderme.

6. Application Gateway'i doğrulama:

   # Get Application Gateway public IP
   $APPGW_IP = az network public-ip show `
       --name $APPGW_PIP_NAME_R1 `
       --resource-group $RESOURCE_GROUP `
       --query ipAddress -o tsv
   Write-Host "Application Gateway IP: $APPGW_IP"
   
   # Test Application Gateway directly (SkipCertificateCheck because certificate is for domain, not IP)
   Invoke-WebRequest -Uri "https://$APPGW_IP/index.html" -Method Head -SkipCertificateCheck
   

   Beklenen sonuç durum kodu 200'dür. "502 Hatalı Ağ Geçidi" alırsanız arka uç HTTP ayarlarının etkinleştirildiğinden --host-name-from-backend-pool true emin olun.

3. Adım: WAF ilke ayarlarını yapılandırma (isteğe bağlı)

Varsayılan olarak, algılama modunda bir WAF oluşturulur. Önleme modu kötü amaçlı istekleri etkin bir şekilde engeller. Üretimde önleme modunu etkinleştirmeden önce kapsamlı bir şekilde test edin.

Genel trafik desenlerinizi değerlendirin ve Application Gateway örneklerini anlamlı bir kullanıcı hacmine sahip bölgelere dağıtın. Application Gateway'i birden çok bölgeye dağıtıyorsanız, her ek bölge için 2. ve 3. adımları yineleyin (örneğin, Batı ABD 2). Farklı sanal ağ adres alanları (10.2.0.0/16, 10.3.0.0/16 vb.) ve bölgeye özgü değişken sonekleri (R2, R3 vb.) kullanın.

4. Adım: Application Gateway WAF uç noktalarını desteklemek için Traffic Manager mimarisi oluşturma

1. Bu senaryonun diyagramında daha önce gösterildiği gibi performans modunda ikincil bir Traffic Manager örneği oluşturun. Daha fazla bilgi için bkz. Traffic Manager profili oluşturma.

   Tek bölgeli yapılandırma için şu ayrıntıları kullanın:

   • Yönlendirme yöntemi: Öncelik.
   • Endpoint: Tek Application Gateway genel IP adresi.

   Çok bölgeli bir yapılandırma için şu ayrıntıları kullanın:

   • Yönlendirme yöntemi: Performans (kullanıcıları en yakın iyi durumdaki Application Gateway örneğine yönlendirir).
   • Uç noktalar: Bölgeler arasında birden fazla Application Gateway genel IP adresi.
   • Uç nokta konumları: Her uç nokta için Azure bölgesi (performans yönlendirmesi için gereklidir).

   Şu yapılandırma ayarlarını kullanın:

   Setting	Değer	Notes
   Yönlendirme yöntemi	Performans (çok bölgeli) veya Öncelik (tek bölgeli)	Performans , çok bölgeli yapılandırma için gecikme süresini iyileştirir.
   Protokol	HTTPS	HTTPS aracılığıyla Application Gateway durumunu doğrular.
   Port	443	Standart HTTPS bağlantı noktası.
   Path	/health veya /index.html	Application Gateway arka uç sağlığı yoklamasının yolu ile eşleşmelidir.
   TTL	300 saniye	DNS sorgu yükünü ve yanıt hızını dengeler.

   Uyarı

   Varsayılan olarak, Application Gateway için Azure genel IP'leri varsayılan olarak DNS adlarına sahip değildir. Genel IP adresini dns adı değil doğrudan Traffic Manager uç noktaları içinde kullanmanız gerekir. Performans yönlendirmesi için gereklidir ve coğrafi yönlendirmeyi etkinleştirmek için --endpoint-location parametresi gereklidir.

2. Bu senaryonun diyagramında daha önce gösterildiği gibi birincil ağırlıklı/her zaman hizmet veren bir Traffic Manager örneği oluşturun. Daha fazla bilgi için bkz. Traffic Manager profili oluşturma.

   Her iki uç nokta için de şu yapılandırmaları kullanın:

   Setting	Değer	Notes
   Yönlendirme Yöntemi	Ağırlıklı	Uç nokta durumu (etkin veya devre dışı) aracılığıyla el ile denetime izin verir.
   Ağırlık	100
   Protokol	HTTPS	SSL/TLS uç noktalarını doğrulamak için gereklidir.
   Port	443	Standart HTTPS bağlantı noktası.
   Path	/index.html	Sağlık denetimleri için hafif bir uç nokta seçin.
   TTL	300 saniye	DNS TTL. Düşük değerler yük devretmenin daha hızlı gerçekleşmesini sağlar ancak DNS sorgularını artırır.
   Sağlık Kontrolü	Her zaman trafiğe hizmet	Sistem durumu denetimlerini etkinleştirmeyin.

   Bu yapılandırmalar birincil uç noktaya özeldir:

   • Tür: Dış uç nokta

   • Ad: endpoint-afd-primary

   • Tam nitelikli etki alanı adı (FQDN) veya IP adresi: Azure Front Door uç noktasının ana bilgisayar adı (örneğin, myapp-12345.z01.azurefd.net)

   • Uç Noktayı Etkinleştir: Seçili (etkin)

   • Özel Üst Bilgi ayarları: Host=$CUSTOM_DOMAIN (Azure Front Door'un doğru özel etki alanına yönlendirmesi için gereklidir)

   • Sistem Durumu Denetimleri: Her zaman trafiğe hizmet sunma (sistem durumu denetimlerini devre dışı bırakma)

   

   Bu yapılandırmalar ikincil uç noktaya özgü:

   • Tür: Dış uç nokta

   • Ad: endpoint-appgw-secondary

   • Tam etki alanı adı (FQDN) veya IP adresi: İkincil Trafik Yöneticisi FQDN'si (örneğin, myapp-appgw.trafficmanager.net)

   • Uç Noktayı Etkinleştir: Temizlendi (devre dışı)

   

3. Traffic Manager sistem durumunu doğrulayın:

   # Check endpoint health status
   az network traffic-manager profile show `
       --name $ATM_PRIMARY_PROFILE `
       --resource-group $RESOURCE_GROUP `
       --query "{ProfileStatus:profileStatus, MonitorStatus:monitorConfig.profileMonitorStatus, Endpoints:endpoints\[\].{Name:name, Target:target, Priority:priority, Status:endpointMonitorStatus}}"
   

   Her iki uç nokta da Status: Online göstermelidir. Bir uç nokta Degraded veya CheckingEndpoint gösteriyorsa, sistem durumu yoklamalarının bitmesini 1 ila 2 dakika kadar bekleyin.

5. Adım: DNS CNAME'i Traffic Manager'a güncelleştirin ve güncelleştirmeyi doğrulayın

Uyarı

Aşağıdaki adımlar, üretim trafiğinizi Doğrudan Azure Front Door'dan Traffic Manager'a yönlendirir ve olası bir hizmet etkisine neden olur. Devam etmeden önce:

• Bu adımları önce üretim dışı bir ortamda test edin. Örneğin, özel etki alanını Traffic Manager uç noktasına yönlendirmek için üretim dışı bir iş istasyonundaki yerel hosts dosyasını geçici olarak değiştirin. Bu değişiklik, canlı trafiği etkilemeden doğrulamaya olanak tanır.
• Dns CNAME TTL değerinizi, değişiklik yapmanızdan en az 24 saat önce mümkün olan en düşük değere (örneğin, 60-300 saniye) düşürün.
• Mümkünse düşük trafikli dönemlerde bakım penceresi planlayın.
• Sorun çıkması durumunda geri alma yordamlarını hazır bulundurun.

1. DNS CNAME kaydınızı doğrudan Azure Front Door yerine birincil Traffic Manager örneğine işaret eden şekilde güncelleştirin.

   Veri Alanı	Eski değer	Yeni değer
   Ad/Ana Bilgisayar	www	www (değişiklik yok)
   Değer/Gösteren	Azure Front Door uç noktasının ana bilgisayar adı	$ATM_DNS_NAME.trafficmanager.net

2. Traffic Manager çözümünü doğrulayın:

   # Verify Traffic Manager profile is resolving
   nslookup "$ATM_DNS_NAME.trafficmanager.net"
   

   Test, Azure Front Door uç noktasının IP adresini döndürmelidir.

3. DNS yayma işlemini bekleyin ve ardından HTTPS bağlantısını test edin. DNS yayma işlemi genellikle 5-10 dakika sürer, ancak genel olarak 48 saate kadar sürebilir.

   # Check DNS from different resolvers
   nslookup $CUSTOM_DOMAIN 8.8.8.8 # Google DNS
   
   # Test HTTPS connectivity
   Invoke-WebRequest -Uri "https://$CUSTOM_DOMAIN/index.html" -Method Head
   

   Bu test 200 durum kodunu döndürmelidir.

4. DNS tam geçişi sonrasında aşağıdaki Azure Front Door ölçümlerini etkin bir şekilde izleyin:

   • İstek sayısı: Sayı, trafikte herhangi bir düşüş olmadan tutarlı kalmalıdır.

   • Yanıt süresi: Süre normal aralıklar içinde kalmalıdır.

   • Hata oranları: 4xx/5xx hataları artmamalıdır.

   • Kaynak sistem durumu: Arka uç sistem durumu olarak kalmalıdır Online.

6. adım: Yük devri yordamlarını test yapın

1. Azure Front Door hatası simülasyonu (Application Gateway'e el ile yük devretme):

   # Manual failover to Application Gateway
   # Disable Azure Front Door endpoint
   az network traffic-manager endpoint update `
       --name "endpoint-afd-primary" `
       --profile-name $ATM_PRIMARY_PROFILE `
       --resource-group $RESOURCE_GROUP `
       --type externalEndpoints `
       --endpoint-status Disabled
   
   # Enable secondary Traffic Manager endpoint (Application Gateway)
   az network traffic-manager endpoint update `
       --name "endpoint-appgw-secondary" `
       --profile-name $ATM_PRIMARY_PROFILE `
       --resource-group $RESOURCE_GROUP `
       --type externalEndpoints `
       --endpoint-status Enabled
   
   # Verify Traffic Manager endpoint status
   az network traffic-manager endpoint list `
       --profile-name $ATM_PRIMARY_PROFILE `
       --resource-group $RESOURCE_GROUP `
       --query "[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus}" `
       --output table
   
   # Flush DNS cache (Windows)
   ipconfig /flushdns
   
   # Verify DNS resolution (should now point to secondary Traffic Manager instance and Application Gateway)
   nslookup $CUSTOM_DOMAIN
   
   # Test - should now work via Application Gateway
   curl --head https://$CUSTOM_DOMAIN/
   

   Uyarı

   DNS TTL, yük devretme süresini etkiler. 60 saniyelik TTL ile istemcilerin değişikliği görmesi 60 saniyeye kadar sürebilir. Çözümlemenin Application Gateway'e işaret ettiğini doğrulamak için kullanın nslookup .

2. Azure Front Door'a geri dönün:

   # Re-enable Azure Front Door endpoint
   az network traffic-manager endpoint update `
       --name "endpoint-afd-primary" `
       --profile-name $ATM_PRIMARY_PROFILE `
       --resource-group $RESOURCE_GROUP `
       --type externalEndpoints `
       --endpoint-status Enabled
   
   # Disable Application Gateway (via Secondary Traffic Manager)
   az network traffic-manager endpoint update `
       --name "endpoint-appgw-secondary" `
       --profile-name $ATM_PRIMARY_PROFILE `
       --resource-group $RESOURCE_GROUP `
       --type externalEndpoints `
       --endpoint-status Disabled
   
   # Verify endpoint status
   az network traffic-manager endpoint list `
       --profile-name $ATM_PRIMARY_PROFILE `
       --resource-group $RESOURCE_GROUP `
       --query "[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus}" `
       --output table
   
   # Flush DNS cache (Windows)
   ipconfig /flushdns
   
   # Verify DNS resolution (should now point back to Azure Front Door)
   nslookup $CUSTOM_DOMAIN
   
   # Test - should now work via Azure Front Door
   curl --head https://$CUSTOM_DOMAIN/
   

3. Geçerli yönlendirmeyi doğrulayın:

   # Check which endpoint is serving traffic
   nslookup $CUSTOM_DOMAIN
   
   Invoke-WebRequest -Uri "https://$CUSTOM_DOMAIN/index.html" -Method Head | Select-Object -ExpandProperty Headers
   

   Yanıt üst bilgileri, hizmet veren uç noktayı tanımlamaya yardımcı olabilir.

   • Azure Front Door, x-azure-ref header’ını içerir.
   • Application Gateway üzerinden geçen trafik Server: Microsoft-IIS veya benzerini içerebilir.

Senaryo 2: Traffic Manager'ın Azure Front Door'dan alternatif bir CDN'ye yük devretmesi

Bu çözüm, Azure Front Door ile alternatif bir CDN arasındaki trafiği el ile değiştirebilmeniz için ağırlıklı/her zaman hizmet veren yönlendirmeye sahip tek bir Traffic Manager profili kullanır.

• Birincil uç nokta: Azure Front Door'un özel etki alanı uç noktası.

• İkincil uç nokta: Alternatif CDN uç noktası.

• Trafik akışı (normal işlem):Kullanıcı → Dns sorgusu → Traffic Manager (ağırlıklı/her zaman hizmet yönlendirme) → Azure Front Door (öncelik 1) → kaynak sunucuları.

• Trafik akışı (Azure Front Door hatası): Kullanıcı → DNS sorgusu → Trafik Yöneticisi (ağırlıklı/her zaman hizmet yönlendirme) → alternatif CDN (öncelik 2) → kaynak sunucuları.

Önemli uygulama adımları

1. Adım: Önkoşulları sağlama

İkincil CDN sağlayıcınızı şu şekilde yapılandırın:

• Azure Front Door özel etki alanı ve BYO sertifikasıyla yapılandırıldı.

• Alternatif bir CDN hesabı.

• CNAME kaydınız için daha düşük bir DNS TTL değeri, Azure Front Door'un trafiği en düşük zaman ayarına sunmasını sağlar.

• Hem Azure Front Door hem de alternatif CDN'nin erişebildiği kaynak sunucular.

• DNS kayıtlarını değiştirebilen özel bir etki alanı.

Önemli

Şu anda Azure Front Door tarafından yönetilen sertifikalar kullanıyorsanız, bu HA çözümünü uygulamadan önce BYO sertifikalarına geçmeniz gerekir. Azure Front Door tarafından yönetilen sertifikalar dışarı aktarılamaz ve alternatif CDN'lere yüklenemez. BYO sertifikaları hakkında daha fazla bilgi ve yapılandırma yönergeleri için bkz. Azure Front Door özel etki alanında HTTPS'yi yapılandırma.

2. Adım: Alternatif cdn yapılandırma

İkincil CDN sağlayıcınızı yapılandırın:

• CdN bölgesini veya özelliğini özel etki alanınızla ayarlayın.

• Kaynak sunucuları, Azure Front Door arka uç havuzunu yapılandırdığınız gibi yapılandırın.

• BYO SSL/TLS sertifikasını karşıya yükleyin. Bu sertifika, Azure Front Door'da kullandığınız sertifikayla aynıdır.

• CDN önbelleğe alma kurallarını Azure Front Door davranışıyla eşleşecek şekilde yapılandırın. Örneğin, önbellek sürelerini ve sorgu dizesi işlemeyi yapılandırın.

• Önbelleğe alma ayarlarını, denetim üst bilgilerini ve sıkıştırma ayarlarını Azure Front Door yapılandırmanızla eşleşecek şekilde ayarlayın.

• CDN sağlayıcısı WAF özellikleri sunuyorsa WAF kurallarını ayarlayın. Azure Front Door WAF ilkesiyle eşleştirmeyi deneyin.

• Özel etki alanını Azure Front Door özel etki alanınızla eşleşecek şekilde yapılandırın (örneğin, www.contoso.com).

• Traffic Manager yapılandırması için CDN kenarının ana bilgisayar adını kaydedin (örneğin, your-site.cdn.provider.net).

3. Adım: Traffic Manager profili oluşturma

Traffic Manager profilini oluşturmak için aşağıdaki yapılandırmaları uygulayın. Daha fazla bilgi için bkz. Traffic Manager profili oluşturma.

Setting	Değer	Notes
Yönlendirme Yöntemi	Ağırlıklı	Uç nokta durumu (etkin veya devre dışı) aracılığıyla el ile denetime izin verir.
Ağırlık	100	Traffic Manager profili oluşturulduğunda ve her iki uç nokta için 100 girin.
Protokol	HTTPS	SSL/TLS uç noktalarını doğrulamak için gereklidir.
Port	443	Standart HTTPS bağlantı noktası.
Path	/index.html	Sağlık denetimleri için hafif bir uç nokta seçin.
TTL	300 saniye	DNS TTL. Düşük değerler yük devretmenin daha hızlı gerçekleşmesini sağlar ancak DNS sorgularını artırır.

4. Adım: Traffic Manager uç noktalarını yapılandırma

Traffic Manager profilinde iki uç nokta oluşturun.

Birincil uç nokta (Azure Front Door) için şu yapılandırmaları kullanın:

• Tür: Dış uç nokta

• Ad: endpoint-afd-primary

• Tam etki alanı adı (FQDN) veya IP adresi: Azure Front Door uç noktasının ana bilgisayar adı (örneğin, myapp-endpoint-12345.z01.azurefd.net)

• Ağırlık: 100

• Uç Noktayı Etkinleştir: Başlangıçta seçili (etkin)

• Özel Üst Bilgi ayarları: Host=$CUSTOM_DOMAIN (Azure Front Door'un doğru özel etki alanına yönlendirmesi için gereklidir)

• Sistem Durumu Denetimleri: Her zaman trafiğe hizmet sunma (sistem durumu denetimlerini devre dışı bırakma)

Uyarı

--custom-headers "Host=$CUSTOM_DOMAIN" Parametresi, Azure Front Door uç noktaları için kritik öneme sahiptir. Bu özellik olmadan Azure Front Door istekleri özel etki alanı yapılandırmanıza düzgün şekilde yönlendirmeyebilir. Azure Traffic Manager'ın desteklenen bir özelliğidir.

İkincil uç nokta (alternatif CDN) için şu yapılandırmaları kullanın:

• Tür: Dış uç nokta

• Ad: endpoint-cdn-secondary

• Tam nitelikli alan adı (FQDN) veya IP adresi: CDN uç sunucu adı (örneğin, myapp.cdn.net)

• Ağırlık: 100

• Uç Noktayı Etkinleştir: Bekleme modu için başlangıçta temizlendi (devre dışı)

5. Adım: DNS CNAME'i Traffic Manager'a güncelleştirin ve güncelleştirmeyi doğrulayın

Uyarı

Aşağıdaki adımlar üretim trafiğinizi Doğrudan Azure Front Door'dan Traffic Manager'a yönlendirir. Devam etmeden önce:

• Bu adımları önce üretim dışı bir ortamda test edin.
• Dns CNAME TTL değerinizi, değişiklik yapmanızdan en az 24 saat önce mümkün olan en düşük değere (örneğin, 60-300 saniye) düşürün.
• Mümkünse düşük trafikli dönemlerde bakım penceresi planlayın.
• Sorun çıkması durumunda geri alma yordamlarını hazır bulundurun.

1. DNS CNAME kaydınızı doğrudan Azure Front Door yerine Traffic Manager'a işaret eden şekilde güncelleştirin:

   Veri Alanı	Eski değer	Yeni değer
   Ad/Sunucu	www	www (değişiklik yok)
   Değer/İşaret Edilen	Azure Front Door uç noktasının ana bilgisayar adı	$ATM_CDN_DNS_NAME.trafficmanager.net

   DNS yayma işlemi genellikle 5-10 dakika sürer, ancak genel olarak 48 saate kadar sürebilir.

2. Traffic Manager çözümünü doğrulayın. DNS yayma işlemini bekleyin ve ardından HTTPS bağlantısını test edin.

   # Verify Traffic Manager profile is resolving
   nslookup "$ATM_CDN_DNS_NAME.trafficmanager.net"
   # Expected result: Should return IP address of Azure Front Door endpoint
   
   # Check DNS from different resolvers
   nslookup $CUSTOM_DOMAIN 8.8.8.8    # Google DNS
   
   # Test HTTPS connectivity
   Invoke-WebRequest -Uri "https://$CUSTOM_DOMAIN/index.html" -Method Head
   # Expected result: Status code 200
   

3. DNS tam geçişi sonrasında aşağıdaki Azure Front Door ölçümlerini etkin bir şekilde izleyin:

   • İstek sayısı: Sayı, trafikte herhangi bir düşüş olmadan tutarlı kalmalıdır.

   • Yanıt süresi: Süre normal aralıklar içinde kalmalıdır.

   • Hata oranları: 4xx/5xx hataları artmamalıdır.

   • Kaynak sağlığı: Arka uç sistem sağlığı aynı kalmalıdır Online.

6. adım: Yük devri yordamlarını test yapın

1. Alternatif CDN'ye el ile yük devretme:

   # Failover: Disable Azure Front Door and enable CDN
   az network traffic-manager endpoint update `
       --name "endpoint-afd-primary" `
       --profile-name $ATM_CDN_PROFILE_NAME `
       --resource-group $RESOURCE_GROUP `
       --type externalEndpoints `
       --endpoint-status Disabled
   
   az network traffic-manager endpoint update `
       --name "endpoint-cdn-secondary" `
       --profile-name $ATM_CDN_PROFILE_NAME `
       --resource-group $RESOURCE_GROUP `
       --type externalEndpoints `
       --endpoint-status Enabled
   
   # Verify endpoint status
   az network traffic-manager profile show `
       --name $ATM_CDN_PROFILE_NAME `
       --resource-group $RESOURCE_GROUP `
       --query "endpoints[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus, Target:target}"
   
   # Flush local DNS cache and verify resolution
   ipconfig /flushdns
   nslookup "$ATM_CDN_DNS_NAME.trafficmanager.net"
   
   # Test HTTPS access
   curl --head https://$CUSTOM_DOMAIN/
   

2. Azure Front Door'a geri dönün:

   # Failback: Enable Azure Front Door, disable CDN
   az network traffic-manager endpoint update `
       --name "endpoint-afd-primary" `
       --profile-name $ATM_CDN_PROFILE_NAME `
       --resource-group $RESOURCE_GROUP `
       --type externalEndpoints `
       --endpoint-status Enabled
   
   az network traffic-manager endpoint update `
       --name "endpoint-cdn-secondary" `
       --profile-name $ATM_CDN_PROFILE_NAME `
       --resource-group $RESOURCE_GROUP `
       --type externalEndpoints `
       --endpoint-status Disabled
   
   # Verify
   az network traffic-manager profile show `
       --name $ATM_CDN_PROFILE_NAME `
       --resource-group $RESOURCE_GROUP `
       --query "endpoints[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus}"
   

İzleme

Önemli

Yapay izleyicileri, hatalarla ilgili anında uyaracak şekilde yapılandırın. Bu uyarılar, otomatik yük devretme yetersizse (örneğin, Traffic Manager'ın algılayamadığı Azure Front Door özel etki alanı sorunları gibi) manuel yük devretmeyi tetiklemelidir.

Üretim ortamları için aşağıdaki izleme çözümlerini öneririz:

• Azure Monitor çalışma kitapları: Traffic Manager sorgularını, Azure Front Door isteklerini ve Application Gateway durumunu izleyin. Daha fazla bilgi için bkz. Çalışma kitaplarına genel bakış.

• Genel Azure Front Door sorunlarını algılamak için dışarıdan izleme: Uç noktaları izlemek için dışarıdan yapay izleme çözümleri (Catchpoint veya ThousandEyes gibi) uygulayın. WebPageTest gibi hizmetler, sınırlı genel görünürlük sağlayan ücretsiz bir alternatif sunar.

• Application Insights kullanılabilirlik testleri: Çok bölgeli HTTP denetimleri kullanın. Daha fazla bilgi için bkz. Application Insights kullanılabilirlik testleri.

• DNS izleme: DNSPerf, Pingdom veya Uptime.com aracılığıyla CNAME çözümleme zincirini ve TTL yayma işlemini doğrulayın.

• Sertifika izleme: Sunucunuzun yapılandırmasını analiz etmek için Qualys SSL Labs'den SSL Sunucu Testi'ni kullanın.