Uçlar arası ağ iletişimi

Azure'daki en yaygın ağ tasarımı desenleri, isteğe bağlı olarak Azure ExpressRoute aracılığıyla şirket içi ağlara veya genel İnternet üzerinden siteden siteye sanal özel ağ (VPN) tünellerine bağlı bir veya birden çok Azure bölgesinde merkez-uç sanal ağ topolojileri oluşturmayı içerir.

Tasarım kılavuzlarının çoğu, iç, şirket içi ağlardaki veya İnternet'teki kullanıcılardan bu sanal ağlara yönelik uygulama trafiğine odaklanır (genellikle ağ diyagramlarında dikey çizgilerle temsil edildiğinden, endüstrinin genellikle kuzey-güney trafiğini belirlemesi). Bu makale, doğu-batı trafiği için kullanılabilen çeşitli desenlere odaklanmaktadır. Başka bir ifadeyle, Azure sanal ağlarında dağıtılan iş yükleri arasındaki iletişim akışları tek bir bölgede veya farklı bölgelerde gerçekleşir.

Ağ tasarımınızın doğu-batı trafiği gereksinimlerini karşıladığından emin olmak, Azure'da çalışan uygulamalarınıza performans, ölçeklenebilirlik ve dayanıklılık sağlama açısından kritik öneme sahiptir.

Olası kullanım örnekleri

Uç-uç trafiği çeşitli senaryolarda önemli olabilir:

• Tek bir uygulamanın farklı katmanları ayrı sanal ağlarda yer alır. Örneğin, bir çevre sanal ağındaki çevre ağı sunucuları (DMZ sunucuları olarak da bilinir) iç sanal ağdaki uygulama hizmetleriyle iletişim kurar.
• Farklı ortamlardaki (Geliştirme, Hazırlama, Üretim) uygulama iş yüklerinin verileri birbirleri arasında çoğaltması gerekir.
• Farklı uygulamaların veya mikro hizmetlerin birbiriyle iletişim kurması gerekir.
• Olağanüstü bir durumda iş sürekliliğini garanti etmek için veritabanlarının verileri bölgeler arasında çoğaltması gerekir.
• Kullanıcılar Azure sanal ağlarının içindedir. Örneğin, Azure Sanal Masaüstü'nü kullanırlar.

Uçlar arası iletişim için desenler ve topolojiler

Birden çok sanal ağı geçen Azure tasarımlarında kullanabileceğiniz iki ana topoloji vardır: geleneksel merkez-uç ve Azure Sanal WAN. Microsoft, Sanal WAN bir ortamda merkez sanal ağını ve içindeki her şeyi yönetir. Geleneksel merkez-uç ortamında merkez sanal ağını yönetirsiniz.

Sanal WAN ve merkez-uç topolojileri, iş yüklerinin uç sanal ağlarında çalıştığı ve şirket içi bağlantının merkez sanal ağında merkezileştirildiği mimarilere örnektir. Bu makalede açıklanan kavramların çoğu hem merkez-uç hem de Sanal WAN tasarımlar için geçerlidir.

Uç sanal ağlarını birbirine bağlamak için iki ana desen vardır:

• Uçlar birbiriyle doğrudan bağlantılıdır. Merkez sanal ağından geçmeden doğrudan bağlantı sağlamak için uç sanal ağları arasında sanal ağ eşlemeleri veya VPN tünelleri oluşturulur.
• Uçlar bir ağ gereci üzerinden iletişim kurar. Her uç sanal ağının Sanal WAN veya merkez sanal ağına yönelik bir eşlemesi vardır. Bir alet trafiği uçtan uca yönlendirir. Alet Microsoft tarafından (Sanal WAN gibi) veya sizin tarafınızdan yönetilebilir.

Desen 1: Doğrudan birbirine bağlı uçlar

Uçlar arasındaki doğrudan bağlantılar genellikle bir merkez genelinde ağ sanal gereci (NVA) üzerinden geçen bağlantılardan daha iyi aktarım hızı, gecikme süresi ve ölçeklenebilirlik sunar. NVA'lar farklı bir kullanılabilirlik alanındaysa ve hub üzerinden trafik gönderildiğinde en az iki sanal ağ eşlemesinin geçmesi gerekiyorsa NVA'lar aracılığıyla trafik göndermek trafiğe gecikme süresi ekleyebilir. İki uçlu sanal ağı birbirine doğrudan bağlamak için çeşitli seçenekler vardır: sanal ağ eşlemesi, Azure Sanal Ağ Manager ve VPN tünelleri.

• Sanal ağ eşlemesi. Uçlara göre doğrudan sanal ağ eşlemelerinin avantajları şunlardır:

  • Daha az sanal ağ eşleme atlamaları gerektiğinden daha düşük maliyet.
  • Daha iyi performans, çünkü trafiğin gecikme süresine veya olası performans sorunlarına neden olan herhangi bir ağ aletinden geçmesi gerekmez.

  Diğer senaryolar arasında kiracılar arası bağlantı yer alır. Ancak uç sanal ağları arasındaki trafiği incelemeniz gerekebilir ve bu da merkez sanal ağındaki merkezi ağ cihazları aracılığıyla trafik gönderilmesini gerektirebilir.

• Azure Sanal Ağ Yöneticisi. Azure Sanal Ağ Manager, sanal ağ eşlemesinin sunduğu avantajlara ek olarak, sanal ağ ortamlarını yönetmenize ve büyük ölçekte bağlantı oluşturmanıza olanak tanıyan bir yönetim hizmeti sağlar. Azure Sanal Ağ Yöneticisi'ni kullanarak abonelikler arasında hem mevcut hem de yeni sanal ağlar için üç tür topoloji oluşturabilirsiniz:

  • Birbirine bağlı olmayan uçlarla merkez-uç.

  • Ortada herhangi bir atlama olmadan birbirine doğrudan bağlı uçlarla merkez ve uç.

  • Birbirine bağlı, ağ bağlantılı bir sanal ağ grubu.

    

    Bu makaledeki tüm Visio diyagramlarını indirin.

    Azure Sanal Ağ Manager ile uçların birbirine bağlı olduğu bir merkez-uç topolojisi oluşturduğunuzda, aynı ağ grubundaki uç sanal ağları arasındaki doğrudan bağlantı otomatik olarak çift yönlü olarak oluşturulur. Azure Sanal Ağ Yöneticisi'ni kullanarak uç sanal ağlarını statik veya dinamik olarak belirli bir ağ grubunun üyeleri haline getirebilirsiniz ve bu da herhangi bir sanal ağ için bağlantıyı otomatik olarak oluşturur.

    Uç sanal ağ kümelerini doğrudan bağlantıdan yalıtmak için birden çok ağ grubu oluşturabilirsiniz. Her ağ grubu, uç-uç bağlantısı için aynı bölgeyi ve çok bölgeli desteği sağlar. Azure Sanal Ağ Manager ile ilgili olarak Azure Sanal Ağ Manager hakkında SSS bölümünde açıklanan maksimum sınırların altında kalmayı unutmayın.

• Sanal ağları bağlayan VPN tünelleri. Vpn hizmetlerini, Microsoft VPN ağ geçitlerini veya üçüncü taraf VPN NVA'larını kullanarak uç sanal ağlarına doğrudan bağlanacak şekilde yapılandırabilirsiniz. Bu seçeneğin avantajı, uç sanal ağlarının aynı bulut sağlayıcısındaki ticari ve bağımsız bulutlar arasında bağlanması veya bulutlar arası sağlayıcılar arasında bağlantı kurmasıdır. Ayrıca, her uç sanal ağında yazılım tanımlı geniş alan ağı (SD-WAN) NVA'ları varsa, bu yapılandırma sanal ağ bağlantısını yönetmek için üçüncü taraf sağlayıcının denetim düzlemini ve özellik kümesini kullanmayı kolaylaştırabilir.

  Bu seçenek, MACsec şifrelemesi tarafından henüz sağlanmayan tek bir Azure veri merkezinde sanal ağlar arasında trafiğin şifrelenmesinin uyumluluk gereksinimlerini karşılamanıza da yardımcı olabilir. Ancak bu seçenek, IPsec tünellerinin bant genişliği sınırları (tünel başına 1,25 Gb/sn) ve hem merkez hem de uç sanal ağlarında sanal ağ geçitlerine sahip olma tasarım kısıtlamaları nedeniyle kendi zorluklarıyla birlikte gelir: Uç sanal ağının bir sanal ağ geçidi varsa, Sanal WAN bağlanamaz veya şirket içi ağlara bağlanmak için hub'ın sanal ağ geçidini kullanamaz.

Desen 1: Tek bölge

Uç sanal ağlarını birbirine bağlamak için kullandığınız teknolojiden bağımsız olarak, ağ topolojileri tek bir bölge için şöyle görünür:

Desen 1: Birden çok bölge

Tüm uç sanal ağlarını birbirine bağlayan tasarımlar da birden çok bölgeye genişletilebilir. Bu topolojide Azure Sanal Ağ Manager, gerekli çok sayıda bağlantıyı korumanın yönetim yükünü azaltmak için daha da kritik öneme sahiptir.

Uç sanal ağlarını birbirine tam olarak ağa bağlı bir topolojide doğrudan bağladığınızda, gerekli olabilecek yüksek sayıda sanal ağ eşlemesini göz önünde bulundurmanız gerekir. Aşağıdaki diyagramda bu sorun gösterilmektedir. Bu senaryoda, sanal ağ bağlantılarını otomatik olarak oluşturabilmeniz için Azure Sanal Ağ Yöneticisi kesinlikle önerilir.

Desen 2: Ağ gereci üzerinden iletişim kuran uçlar

Uç sanal ağlarını birbirine doğrudan bağlamak yerine, uçlar arasındaki trafiği iletmek için ağ gereçlerini kullanabilirsiniz. Ağ gereçleri derin paket denetimi ve trafik segmentasyonu veya izleme gibi ek ağ hizmetleri sağlar, ancak düzgün boyutlandırılmamaları durumunda gecikme ve performans sorunlarına yol açabilir. Bu gereçler genellikle uçların bağlanacakları bir merkez sanal ağında bulunur. Uçlar arasında trafiği iletmek için ağ gereci kullanmak için birden çok seçenek vardır:

• Sanal WAN hub yönlendiricisi. Microsoft tarafından tam olarak yönetilen Sanal WAN, trafiği uçlardan çeken ve ExpressRoute veya siteden siteye veya noktadan siteye VPN tünelleri aracılığıyla Sanal WAN veya şirket içi ağlara bağlı başka bir sanal ağa yönlendiren bir sanal yönlendirici içerir. Sanal WAN yönlendiricisinin ölçeği otomatik olarak artırılıp azaltılarak, yalnızca uçlar arasındaki trafik hacminin Sanal WAN sınırları içinde kaldığından emin olmanız yeterlidir.

• Azure Güvenlik Duvarı. Azure Güvenlik Duvarı, Microsoft tarafından yönetilen ve yönettiğiniz hub sanal ağlarında veya Sanal WAN hub'larda dağıtılabilir bir ağ gerecidir. IP paketlerini iletebilir ve ayrıca bunları inceleyebilir ve ilkelerde tanımlanan trafik kesimleme kurallarını uygulayabilir. Performans sorununa neden olmaması için Azure Güvenlik Duvarı sınırlarına kadar otomatik ölçeklendirme sağlar. Azure Güvenlik Duvarı yalnızca Sanal WAN ile kullanıldığında kullanıma sunulan çok bölgeli özellikler sağladığını unutmayın. Sanal WAN olmadan, bölgeler arası uçlar arası iletişim elde etmek için kullanıcı tanımlı yollar uygulamanız gerekir.

• Üçüncü taraf ağ sanal gereçleri. Yönlendirme ve ağ segmentasyonu gerçekleştirmek için Bir Microsoft iş ortağından bir ağ sanal gereci kullanmayı tercih ediyorsanız, ağ sanal gereçlerini merkez-uç veya Sanal WAN topolojisinde dağıtabilirsiniz. Daha fazla bilgi için bkz. Sanal WAN hub'ına yüksek oranda kullanılabilir NVA'lar veya NVA'lar dağıtma. Ağ sanal gerecinin, uçlar arası iletişimlerin oluşturduğu bant genişliğini desteklediğinden emin olmanız gerekir.

• Azure VPN Gateway. Azure VPN ağ geçidini bir sonraki atlama türü olarak kullanıcı tanımlı yol olarak kullanabilirsiniz, ancak Microsoft uç uca trafiği yönlendirmek için VPN sanal ağ geçitlerinin kullanılmasını önermez. Şirket içi sitelere veya VPN kullanıcılarına giden trafiği şifrelemek için tasarlanmıştır. Örneğin, vpn ağ geçidinin yönlendirebileceği uçlar arasındaki bant genişliğinin garantisi yoktur.

• ExpressRoute. Belirli yapılandırmalarda ExpressRoute ağ geçidi, uç-uç iletişimini çeken yolları tanıtabilir ve trafiği hedef uça yönlendirildiği Microsoft edge yönlendiricisine gönderir. Microsoft, Microsoft omurga ucuna ve arkasına trafik göndererek gecikme süresi sunduğundan, Microsoft bu senaryoyu kesinlikle önerilmez. Üstelik Microsoft, tek hata noktası ve büyük patlama yarıçapı nedeniyle bu yaklaşımı önermez. Bu senaryo ayrıca ExpressRoute altyapısına (ağ geçidi ve fiziksel yönlendiriciler) fazladan baskı uygulamadan kaynaklanan birden çok sorun sunar. Bu ek basınç paket düşüşlerine neden olabilir.

Merkezi NVA'lara sahip merkez-uç ağ tasarımlarında alet genellikle hub'a yerleştirilir. Merkez-uç sanal ağları arasındaki sanal ağ eşlemelerinin Azure Sanal Ağ Manager ile el ile veya otomatik olarak oluşturulması gerekir:

• El ile sanal ağ eşlemeleri. Düşük sayıda uç sanal ağınız olduğunda bu yaklaşım yeterlidir, ancak büyük ölçekte yönetim yükü oluşturur.

• Azure Sanal Ağ Yöneticisi. Daha önce belirtildiği gibi Azure Sanal Ağ Manager, sanal ağ ortamlarını ve eşlemelerini büyük ölçekte yönetmeye yönelik özellikler sağlar. Merkez-uç sanal ağları arasındaki eşleme yapılandırmaları, ağ grupları için otomatik olarak çift yönlü olarak yapılandırılır.

  Azure Sanal Ağ Manager, yeni üyeler için eşleme bağlantısını otomatik olarak oluşturan belirli bir ağ grubuna uç sanal ağ üyeliklerini statik veya dinamik olarak ekleme olanağı sağlar. Ağ gruplarındaki uç sanal ağları, bağlantı için merkez VPN veya ExpressRoute ağ geçitlerini kullanabilir. Azure Sanal Ağ Yöneticisi için en yüksek sınırların altında kalmayı unutmayın.

Desen 2: Tek bölge

Aşağıdaki diyagramda, merkez sanal ağına dağıtılan bir Azure güvenlik duvarı aracılığıyla uçlar arasında trafik gönderen tek bölgeli merkez-uç topolojisi gösterilmektedir. Trafik, uç alt ağlarına uygulanan kullanıcı tanımlı yollar aracılığıyla merkezdeki merkezi alete iletilir.

Belirli durumlarda, ölçeklenebilirlik için uç-uç ve İnternet trafiğini işleyen ağ sanal gereçlerini ayırmak yararlı olabilir. Bu ayrımı şu şekilde gerçekleştirebilirsiniz:

• Uçlardaki yol tablolarının ayarlanması, özel adresleri (RFC 1918 ön ekleri için bir yol içerenler) Azure'den Azure'a ve Azure'den şirket içi trafiğe (doğu-batı trafiği olarak da adlandırılır) sorumlu olan bir NVA'ya göndermek için ayarlanır.
• İnternet trafiğini (0.0.0.0/0 yolu olan) ikinci bir NVA'ya ayarlama. Bu NVA, Azure-İnternet trafiğinden (kuzey-güney trafiği olarak da adlandırılır) sorumludur.

Aşağıdaki diyagramda bu yapılandırma gösterilmektedir:

Desen 2: Birden çok bölge

Aynı yapılandırmayı birden çok bölgeye genişletebilirsiniz. Örneğin, Azure Güvenlik Duvarı kullanan bir merkez-uç tasarımında, uzak bölgedeki uçlar için her merkezdeki Azure Güvenlik Duvarı alt ağlarına ek yol tabloları uygulamanız gerekir. Bu yapılandırma, bölgeler arası trafiğin her merkez sanal ağındaki Azure güvenlik duvarları arasında iletilmesini sağlar. Uç sanal ağları arasındaki bölgesel trafik daha sonra her iki Azure güvenlik duvarını da aşıyor. Daha fazla bilgi için bkz. Çoklu merkez ve uç topolojisini yönlendirmek için Azure Güvenlik Duvarı:

Kuzey-güney ve doğu-batı trafiği için ayrı Azure güvenlik duvarları veya ağ sanal gereçleri içeren tasarım varyasyonu, çok bölgeli merkez-uç topolojisinde de mümkündür:

Sanal WAN benzer bir topoloji oluşturur ve yönlendirme karmaşıklığını üstlenir. Bunu hem merkezlerde (Microsoft'un yönettiği) hem de uçlarda (yolların eklenebilir olduğu ve yol tablolarında el ile tanımlanması gerekmeyen) yapar. Bu nedenle ağ yöneticisinin yalnızca uç sanal ağlarını bir Sanal WAN hub'ına bağlaması gerekir ve bölgeler arasında trafiği iletme konusunda endişelenmesi gerekmez.

Karma desenler

Birçok durumda, daha önce açıklanan iki deseni birleştiren karma bir yaklaşım gerekir. Bu yaklaşımda, belirli uçlar arasındaki trafiğin doğrudan bağlantılar üzerinden geçmesi gerekir, ancak uçların geri kalanı merkezi bir ağ gereci aracılığıyla iletişim kurar. Örneğin, Sanal WAN bir ortamda, yüksek bant genişliğine ve düşük gecikme süresi gereksinimlerine sahip iki belirli uçları doğrudan bağlayabilirsiniz. Başka bir senaryo, tek bir ortamın parçası olan uç sanal ağlarını içerir. Örneğin, bir uç Geliştirme sanal ağının doğrudan başka bir uç Geliştirme sanal ağına bağlanmasına izin verebilir, ancak Geliştirme ve Üretim iş yüklerini merkezi gereç üzerinden iletişim kurmaya zorlayabilirsiniz.

Diğer bir yaygın desen, doğrudan sanal ağ eşlemeleri veya Azure Sanal Ağ Manager bağlı grupları aracılığıyla tek bir bölgedeki uçları bağlamayı içerir, ancak bölgeler arası trafiğin NVA'lar arasında geçişine izin verir. Bu modelin temel motivasyonu genellikle mimarideki sanal ağ eşlemelerinin sayısını azaltmaktır. Ancak, ilk modelle (uçlar arasındaki doğrudan bağlantı) karşılaştırıldığında, bu modelde ortaya konan dezavantajlardan biri bölgeler arası trafik için daha fazla sanal ağ eşleme atlamalarıdır. Bu atlamalar, çaprazlanan birden çok sanal ağ eşlemesi nedeniyle maliyetleri artırır. Diğer bir dezavantaj, tüm bölgeler arası trafiğin önüne geçmek için merkez NVA'larına ek yük olmasıdır.

Aynı tasarımlar Sanal WAN için de geçerlidir. Ancak, uç sanal ağları arasındaki doğrudan bağlantının Sanal WAN kaynağı üzerinden değil, doğrudan sanal ağlar arasında el ile yapılandırılması gerektiği dikkate alınmalıdır. Azure Sanal Ağ Manager şu anda Sanal WAN temel alan mimarileri desteklememektedir. Örneğin:

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:

• Jay Li | Kıdemli Ürün Yöneticisi
• Jose Moreno | Baş Müşteri Mühendisi
• Alejandra Palacios | Kıdemli Azure Altyapısı Müşteri Mühendisi

Diğer katkıda bulunanlar:

• Mick Alberts | Teknik Yazar
• Mohamed Hassan | Baş PM Yöneticisi
• Andrea Michael | Program Yöneticisi
• Yasukuni Morishima | Müşteri Mühendisi II
• Jithin PP| Müşteri Mühendisi

Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.

Sonraki adımlar

• Bulut Benimseme Çerçevesi: Giriş bölgesi ağ topolojisi ve bağlantı
• Sanal ağ eşleme
• Azure Sanal Ağ Yöneticisi
• Sanal WAN
• Azure Güvenlik Duvarı
• Azure'da ağ bağlantısının güvenliğini sağlama
• Azure Sanal Ağ'lere giriş

İlgili kaynaklar

• Azure'da merkez-uç ağ topolojisi
• Azure Sanal WAN ile merkez-uç ağ topolojisi
• Geleneksel Azure ağ topolojisi