Azure Route Server ile her noktaya yayın yönlendirmesi
Daha yüksek kullanılabilirlik elde etmek için uygulamanızı tek bir Azure bölgesindeki Kullanılabilirlik Alanları dağıtabilirsiniz, ancak bazen daha yüksek dayanıklılık, dünya genelindeki kullanıcılar için daha iyi bir performans veya daha iyi iş sürekliliği elde etmek için uygulamalarınızı birden çok bölgeye dağıtmanız gerekebilir. Kullanıcıları çok bölgeli bir uygulamanın dağıtıldığı konumlardan birine yönlendirmek için kullanılabilecek farklı yaklaşımlar vardır: Azure Traffic Manager gibi DNS tabanlı yaklaşımlar, Azure Front Door gibi yönlendirme tabanlı hizmetler veya Bölgeler arası Azure Load Balancer.
Önceki Azure hizmetleri, genel IP adresi kullanarak kullanıcıları genel İnternet üzerinden en iyi uygulama konumuna getirmek için önerilir, ancak özel ağları ve IP adreslerini desteklemez. Bu makalede, çok bölgesel, özel ağa bağlı uygulama dağıtımları sağlamak için yol tabanlı bir yaklaşımın (IP anycast) kullanımı incelenmiştir.
IP anycast temelde birden fazla konumdan aynı IP adresinin reklamını içerir, böylece uygulama kullanıcılarından gelen paketler en yakın bölgeye yönlendirilir (yönlendirme açısından). Herhangi bir yayın üzerinde çok bölgeli erişilebilirlik sağlamak, DNS yanıtlarını önbelleğe almayan istemcilere güvenmemek ve uygulamanın DNS tasarımını değiştirmek zorunda kalmadan DNS tabanlı yaklaşımlara göre bazı avantajlar sunar.
Topoloji
Bu senaryonun tasarımında, aynı IP adresi farklı Azure bölgelerindeki sanal ağlardan tanıtılır ve burada ağ sanal gereçleri (NVA'lar) uygulamanın IP adresini Azure Route Server aracılığıyla tanıtılır. Aşağıdaki diyagramda her birinin farklı bir Azure bölgesinde yer alan iki basit merkez-uç topolojisi gösterilmiştir. Her bölgedeki bir NVA, aynı yolu (bu örnekte) yerel Azure Route Sunucusuna tanıtmaktadıra.b.c.d/32 (yol ön eki Azure ve şirket içi ağlarla çakışmamalıdır). Yollar ExpressRoute aracılığıyla şirket içi ağa daha fazla yayılır. Uygulama kullanıcıları uygulamaya şirket içinden erişmek istediğinde, DNS altyapısı (bu belge kapsamında değildir), uygulamanın DNS adını, şirket içi ağ cihazlarının iki bölgeden birine yönlendirdiği herhangi bir yayın IP adresine ()a.b.c.d çözümler.
Kullanılabilir seçenekler arasında bir bölgenin seçilmesi tamamen yönlendirme öznitelikleri tarafından belirlenir. Her iki bölgeden gelen yollar aynıysa, şirket içi ağ genellikle uygulama akışlarını her iki bölgeye eşit olarak dağıtmak için eşit maliyetli çok (ECMP) yönlendirmesi kullanır. Ayrıca, Azure'daki her NVA tarafından oluşturulan yol tanıtımlarını, bir bölgeye göre diğer bölgeye göre öncelik sırasına göre ayarlayabilirsiniz. Örneğin, şirket içi ağdan Azure iş yüküne tercih edilen bir yol oluşturmak için BGP AS Yolu ön ödemesini kullanabilirsiniz.
Önemli
Rotaları tanıtan NVA'lar, kara döşeme trafiğini önlemek için uygulamanın ilgili bölgelerinde kullanılamadığında rotanın reklamını durdurmak için bazı sistem durumu denetimi mekanizması içermelidir.
Dönüş trafiği
Şirket içi istemciden gelen uygulama trafiği Azure'daki NVA'lardan birine ulaştığında, NVA bağlantı ters proxy'si veya Hedef Ağ Adresi Çevirisi (DNAT) gerçekleştirir. Ardından paketleri, genellikle NVA'nın dağıtıldığı merkez sanal ağına eşlenen uç sanal ağında bulunan gerçek uygulamaya gönderir. Uygulamadan gelen trafik NVA'dan geri gider; NVA bağlantıyı ters proxy'lerse (veya Hedef NAT'ye ek olarak Kaynak NAT gerçekleştirirse) doğal olarak gerçekleşir.
Aksi takdirde, uygulamaya gelen trafik hala özgün şirket içi istemcinin IP adresinden kaynaklanır. Bu durumda paketler, kullanıcı tanımlı yollar (UDR) ile NVA'ya geri yönlendirilebilir. Her bölgede birden fazla NVA örneği varsa, trafik asimetrik olabileceğinden (farklı NVA örneklerinden geçen gelen ve giden trafik) özel özen gösterilmelidir. NVA'lar durum bilgisi olmadığında asimetrik trafik genellikle bir sorun değildir, ancak NVA'lar güvenlik duvarları gibi bağlantı durumlarını takip ederse hatalarla sonuçlanır.