Bu makalede, Azure'da yüksek kullanılabilirlik için bir ağ sanal gereçleri (NVA) kümesi dağıtmaya yönelik en yaygın seçenekler açıklanmaktadır. NVA genellikle farklı güvenlik düzeyleriyle sınıflandırılan ağ kesimleri arasındaki trafik akışını denetlemek için kullanılır( örneğin, Militarize Edilmiş Bölge (DMZ) Sanal Ağ ve genel İnternet arasında.
NVA'ların farklı güvenlik bölgeleri arasındaki trafiği incelemek için kullanıldığı bir dizi tasarım deseni vardır, örneğin:
- Sanal makinelerden İnternet'e çıkış trafiğini incelemek ve veri sızdırmayı önlemek için.
- İnternet'ten sanal makinelere giriş trafiğini incelemek ve saldırıları önlemek için.
- Azure'da sanal makineler arasındaki trafiği filtrelemek, güvenliği aşılmış sistemlerin yan yana taşınmasını önlemek için.
- Şirket içi sistemler ile Azure sanal makineleri arasındaki trafiği, farklı güvenlik düzeylerine ait olarak kabul edilirse filtrelemek için. (Örneğin, Azure DMZ'yi barındırıyorsa ve şirket içinde iç uygulamaları barındırıyorsa.)
Ağ güvenlik duvarları, Katman 4 ters proxy'ler, IPsec VPN uç noktaları, web uygulaması güvenlik duvarı işlevselliğine sahip web tabanlı ters proxy'ler, Azure'dan hangi İnternet sayfalarına erişilebileceğini kısıtlayan İnternet proxy'leri, Katman 7 yük dengeleyiciler ve diğerleri gibi birçok NVA örneği vardır. Bunların tümü, bu makalede açıklanan desenlerle bir Azure tasarımına eklenebilir. Azure Güvenlik Duvarı ve Azure Uygulaması Lication Gateway gibi Azure birinci taraf Ağ Sanal Gereçleri bile bu makalenin devamında açıklanan tasarımları kullanır. Bu seçeneklerin anlaşılması hem tasarım açısından hem de ağ sorunlarını giderirken kritik önem taşır.
Yanıtlanması gereken ilk soru, Ağ Sanal Gereçleri için Yüksek Kullanılabilirlik'in neden gerekli olduğudur. Bunun nedeni, bu cihazların ağ kesimleri arasındaki iletişimi denetlemesidir. Bunlar kullanılamıyorsa, ağ trafiği akamaz ve uygulamalar çalışmayı durdurur. Zamanlanmış ve zamanlanmamış kesintiler zaman zaman NVA örneklerini (Azure'daki veya diğer herhangi bir buluttaki diğer sanal makineler gibi) düşürebilir ve düşürebilir. Bu NVA'lar Azure'da tek örnekli bir SLA sağlamak için Premium Yönetilen Diskler ile yapılandırılmış olsa bile örnekler indirilir. Bu nedenle, yüksek oranda kullanılabilir uygulamalar için bağlantının sağlanabilmesi için en az ikinci bir NVA gerekir.
Önkoşullar: Bu makalede Azure ağı, Azure Yük Dengeleyiciler ve Sanal Ağ Trafik Yönlendirmesi (UDR) hakkında temel bilgiler yer alır.
Ağ Sanal Gereci'ni bir Azure sanal ağına dağıtmak için en iyi seçeneği belirlediğinizde dikkate alınması gereken en önemli yön, NVA satıcısının söz konusu tasarımı gözden geçirip doğrulamadığıdır. Satıcı, NVA'nın Azure'da tümleştirilmesi için gereken NVA yapılandırmasını da sağlamalıdır. NVA satıcısı bir NVA için desteklenen tasarım seçenekleri olarak farklı alternatifler sunuyorsa, bu faktörler kararı etkileyebilir:
- Yakınsama süresi: Her tasarımda trafiği başarısız bir NVA örneğinden uzaklaştırmak ne kadar sürer?
- Topoloji desteği: Her tasarım seçeneği hangi NVA yapılandırmalarını destekler? Etkin/etkin, etkin/beklemede, n+1 yedekliliğe sahip ölçeği genişleten NVA kümeleri?
- Trafik simetrisi: Belirli bir tasarım, asimetrik yönlendirmeyi önlemek için NVA'nın paketlerde Kaynak Ağ Adresi Çevirisi (SNAT) gerçekleştirmesini zorlar mı? Yoksa trafik simetrisi başka yollarla mı zorlanıyor?
Belgedeki aşağıdaki bölümlerde NVA'ları Merkez-Uç ağıyla tümleştirmek için kullanılan en yaygın mimariler açıklanmaktadır.
Not
Bu makale Hub & Spoke tasarımlarına odaklanmıştır. Sanal WAN kapsamına Sanal WAN, Sanal WAN hub'larında belirli bir NVA'nın desteklenip desteklenmediğine bağlı olarak NVA'ların nasıl dağıtılacağı konusunda çok daha açıklayıcıdır. Daha fazla bilgi için bkz. Sanal WAN hub'ında Ağ Sanal Gereçleri.
HA mimarilerine genel bakış
Aşağıdaki mimarilerde yüksek oranda kullanılabilir NVA’lar için gerekli kaynaklar ve mimariler açıklanmaktadır:
| Çözüm | Sosyal haklar | Dikkat edilmesi gereken noktalar |
|---|---|---|
| Azure Load Balancer | Etkin/etkin, etkin/bekleme ve ölçeği genişleten NVA'ları destekler. Çok iyi yakınsama süresi | NVA'nın özellikle etkin/hazır bekleyen dağıtımlar için sistem durumu yoklamaları için bir bağlantı noktası sağlaması gerekir. İnternet'e/İnternet'ten gelen akışlar simetri için SNAT gerektirir |
| Azure Route Server | NVA'nın BGP'yi desteklemesi gerekir. Etkin/etkin, etkin/bekleme ve ölçeği genişleten NVA'ları destekler. | Trafik simetrisi SNAT gerektirir |
| Ağ Geçidi Load Balancer | SNAT olmadan trafik simetrisi garanti edilir. NVA'lar kiracılar arasında paylaşılabilir. Çok iyi yakınsama zamanı. Etkin/etkin, etkin/bekleme ve ölçeği genişleten NVA'ları destekler. | İnternet'e/İnternet'ten akışları destekler, Doğu-Batı akışlarını desteklemez |
| PIP/UDR'ı değiştirme | NVA tarafından özel bir özellik gerekmez. Simetrik trafiği garanti eder | Yalnızca aktif/pasif tasarımlar için. 1-2 dakikalık yüksek yakınsama süresi |
Load Balancer tasarımı
Bu tasarımda ağın geri kalanında NVA kümesini kullanıma açmak için iki Azure Load Balancer kullanılır:
- İç Load Balancer, iç trafiği Azure'dan ve şirket içinden NVA'lara yönlendirmek için kullanılır. Bu iç yük dengeleyici HA Bağlantı Noktaları kurallarıyla yapılandırılır, böylece her TCP/UDP bağlantı noktası NVA örneklerine yönlendirilir.
- Genel Load Balancer, NVA'ları İnternet'te kullanıma sunar. HA Bağlantı Noktaları gelen trafiğe yönelik olduğundan, her tcp/UDP bağlantı noktasının ayrılmış bir yük dengeleme kuralında açılması gerekir.
Aşağıdaki diyagramda, İnternet'ten uç sanal ağındaki bir uygulama sunucusuna paketlerin izleyeceği atlama dizisi açıklanmaktadır:
Bu mimarinin bir Visio dosyasını indirin.
NVA'lar aracılığıyla uçlardan genel İnternet'e trafik gönderme mekanizması, iç Load Balancer'ın IP adresini sonraki atlama ile için 0.0.0.0/0 kullanıcı tanımlı bir yoldur.
Azure ile genel İnternet arasındaki trafik için, trafik akışının her yönü farklı bir Azure Load Balancer'ı (genel ALB üzerinden giriş paketi ve iç ALB aracılığıyla çıkış paketi) geçer. Sonuç olarak, trafik simetrisi gerekiyorsa, dönüş trafiğini çekmek ve trafik asimetrisini önlemek için NVA örnekleri tarafından Kaynak Ağ Adresi Çevirisi (SNAT) gerçekleştirilmelidir.
Bu tasarım, Azure ile şirket içi ağlar arasındaki trafiği incelemek için de kullanılabilir:
NVA'lar aracılığıyla uçlar arasında trafik gönderme mekanizması tamamen aynıdır, bu nedenle ek diyagram sağlanmadı. Yukarıdaki örnek diyagramlarda, uç1 uç2'nin aralığını bilmediğinden UDR, 0.0.0.0/0 uç2'ye adreslenen trafiği NVA'nın iç Azure Load Balancer'larına gönderir.
Şirket içi ağlar ile Azure arasındaki veya Azure sanal makineleri arasındaki trafik için, trafik simetrisi iç Azure Load Balancer tarafından garanti edilir: bir trafik akışının her iki yönü de aynı Azure Load Balancer'a geçtiğinde aynı NVA örneği seçilir.
Azure Load Balancer, tek tek NVA kesintileri durumunda çok iyi bir yakınsama süresine sahiptir. Sistem durumu yoklamaları her 5 saniyede bir gönderilebildiği ve 3 başarısız yoklamanın hizmet dışı bir arka uç örneği bildirmesi gerektiğinden, Azure Load Balancer'ın trafiği farklı bir NVA örneğine yakınsayabilmesi genellikle 10-15 saniye sürer.
Bu kurulum hem etkin/etkin hem de etkin/bekleme yapılandırmalarını destekler. Ancak etkin/hazır bekleyen yapılandırmalar için, örnek etkin rolde olmadığı sürece NVA örneklerinin Load Balancer sistem durumu yoklamalarına yanıt vermeyen bir TCP/UDP bağlantı noktası veya HTTP uç noktası sunması gerekir.
L7 yük dengeleyicileri kullanma
Bu tasarımın belirli bir örneği, Azure genel Load Balancer'ı Azure Uygulaması lication Gateway (kendi başına NVA olarak kabul edilebilir) gibi bir Katman 7 yük dengeleyici ile değiştirmektir. Bu durumda, Application Gateway'den gelen trafik sanal ağın içinden kaynaklanacağından ve trafik asimetrisi sorun olmadığından NVA'lar yalnızca önlerinde bir iç Load Balancer gerektirir.
NVA, Katman 7 yük dengeleyiciniz tarafından desteklenmeyen protokoller için gelen trafiği ve potansiyel olarak tüm çıkış trafiğini alıyor olmalıdır. Azure Güvenlik Duvarı NVA ve Azure Uygulaması lication Gateway'i Katman 7 web ters ara sunucusu olarak kullanırken bu yapılandırma hakkında daha fazla bilgi için bkz. Sanal ağlar için Güvenlik Duvarı ve Application Gateway.
Azure Route Server
Azure Route Server , NVA'nın Sınır Ağ Geçidi Protokolü (BGP) aracılığıyla Azure SDN ile etkileşim kurmasını sağlayan bir hizmettir. NVA'lar Azure sanal ağlarında hangi IP ön eklerinin olduğunu öğrenmekle kalmaz, aynı zamanda Azure'daki sanal makinelerin etkin yol tablolarına yol ekleyebilecektir.
Yukarıdaki diyagramda her NVA örneği Azure Route Server ile BGP üzerinden eşlenmiştir. Uç alt ağlarında yol tablosu gerekmez, çünkü Azure Route Server NVA'lar tarafından tanıtılan yolları programlar. Azure sanal makinelerinde iki veya daha fazla yol programlanmışsa, her trafik akışı için NVA örneklerinden birini seçmek için Eşit Maliyetli Çoklu Yol (ECMP) kullanır. Sonuç olarak, trafik simetrisi bir gereksinimse SNAT bu tasarımda bir zorunluluktur.
Bu ekleme yöntemi hem etkin/etkin (tüm NVA'lar Azure Route Server'a aynı yolları tanıtır) hem de etkin/beklemeyi destekler (bir NVA, diğerinden daha kısa bir AS yoluna sahip yolları tanıtır). Azure Route Server en fazla 8 BGP bitişikliği destekler. Bu nedenle, etkin NVA'lardan oluşan bir genişleme kümesi kullanılıyorsa, bu tasarım en fazla 8 NVA örneğini destekler.
Yakınsama süresi bu kurulumda oldukça hızlıdır ve BGP bitişikliğini tutan ve tutma süresi süreölçerlerinden etkilenecektir. Azure Route Server'ın varsayılan tutma süresi ve bekleme süresi zamanlayıcıları (sırasıyla 60 saniye ve 180 saniye) olsa da, NVA'lar BGP bitişiklik kurulumu sırasında daha düşük süreölçerler üzerinde anlaşma yapabilir. Bu süreölçerlerin çok düşük ayarlanması BGP dengesizliklerine yol açabilir.
Bu tasarım, Azure yönlendirmesi ile etkileşim kurması gereken NVA'lar için en yaygın seçenektir; örneğin Azure sanal ağlarında yapılandırılan ön ekleri öğrenmesi veya ExpressRoute özel eşlemeleri üzerinden belirli yolları tanıtılması gereken VPN sonlandırma NVA'ları.
Ağ Geçidi Yük Dengeleyici
Azure Gateway Load Balancer , Kullanıcı Tanımlı Yollar ile trafiği yönlendirmeye gerek kalmadan veri yoluna NVA eklemenin yeni bir yoludur. İş yüklerini bir Azure Load Balancer veya genel IP adresi aracılığıyla kullanıma sunan Sanal Makineler, gelen ve giden trafik saydam olarak farklı bir sanal ağda bulunan NVA kümesine yönlendirilebilir. Aşağıdaki diyagramda, iş yüklerinin uygulamayı Azure Load Balancer aracılığıyla kullanıma sunma olasılığına karşı paketlerin genel İnternet'ten gelen trafik için izlediği yol açıklanmaktadır:
Bu NVA ekleme yönteminin temel avantajlarından biri, trafik simetrisini garanti etmek için Kaynak Ağ Adresi Çevirisi 'nin (SNAT) gerekli olmadığıdır. Bu tasarım seçeneğinin bir diğer avantajı da aynı NVA'ların farklı sanal ağlara/sanal ağlardan gelen trafiği incelemek için kullanılabilmesi ve böylece NVA perspektifinden çok kiracılılık elde edilmesidir. NVA sanal ağı ile iş yükü sanal ağları arasında sanal ağ eşlemesi gerekmez ve iş yükü sanal ağına Kullanıcı Tanımlı Yol gerekmez ve bu da yapılandırmayı önemli ölçüde basitleştirir.
Ağ Geçidi Load Balancer ile hizmet ekleme, Azure genel Load Balancer'a (ve bunların dönüş trafiğine) isabet eden gelen akışlar ve Azure'dan kaynaklanan giden akışlar için kullanılabilir. Azure sanal makineleri arasındaki Doğu-Batı trafiği NVA ekleme için Ağ Geçidi Yük Dengeleyici'yi kullanamaz.
NVA kümesinde Azure Load Balancer sistem durumu denetim yoklamaları, tek tek NVA örneği hatalarını algılamak ve çok hızlı yakınsama süresi (10-15 saniye) elde etmek için kullanılacaktır.
PIP-UDR'ı değiştirme
Bu tasarımın ardındaki fikir, NVA yedekliliği olmadan gerekli olan kuruluma sahip olmak ve NVA'nın kapalı kalma süresinden muzdarip olması durumunda değiştirilmesini sağlamadır. Aşağıdaki diyagramda bir Azure Genel IP adresinin etkin NVA (NVA1) ile nasıl ilişkilendirdiği ve uçlardaki Kullanıcı Tanımlı Yolların sonraki atlama (10.0.0.37) olarak etkin NVA'nın IP adresine nasıl sahip olduğu gösterilmektedir.
Etkin NVA kullanılamaz duruma gelirse, hazır bekleyen NVA genel IP adresini ve uç Kullanıcı Tanımlı Yolları kendisine yeniden eşlemek için Azure API'sini çağırır (veya özel IP adresini de taşır). Bu API çağrılarının etkili olması birkaç dakika sürebilir, bu nedenle bu tasarım bu belgedeki tüm seçeneklerin en kötü yakınsama süresini sunar.
Bu tasarımın bir diğer sınırlaması da yalnızca etkin/bekleme yapılandırmalarının desteklenmesidir ve bu da ölçeklenebilirlik sorunlarına yol açabilir: NVA'larınız tarafından desteklenen bant genişliğini artırmanız gerekiyorsa, bu tasarımın tek seçeneği her iki örneğin ölçeğini artırmaktır.
Bu tasarımın avantajlarından biri, belirli bir noktada yalnızca bir NVA etkin olduğundan trafik simetrisini garanti etmek için Kaynak Ağ Adresi Çevirisi (SNAT) gerekli olmamasıdır.
Katkıda Bulunanlar
Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.
Asıl yazarlar:
- Keith Mayer | Ana Bulut Çözümü Mimarı
- Telmo Sampaio | Baş Hizmet Mühendisliği Yöneticisi
Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.