Çok bölgeli ağ tasarımı

Bu makalede, birden çok bölgeye yayılan Azure ağların nasıl tasarlandığını açıklanmaktadır. Çok bölgeli ağ, bölgesel kesintilere karşı yüksek kullanılabilirlik sağlar, coğrafi olarak dağıtılmış kullanıcılara daha düşük gecikme süresiyle hizmet verir ve yasal veri yerleşimi gereksinimlerini destekler.

Bu makalenin kapsamı

Bu makalede alanlar arası yedeklilik, bölgeler arası yönlendirme stratejileri, çok bölgeli dağıtımlar için merkez topolojisi seçimleri, etkin-etkin ve etkin-pasif yük devretme desenleri ve çoğaltma gecikme süresi konuları ele alınıyor.

Bu makaleye kimin ihtiyacı var?

Ortamınız bu koşullardan herhangi biri ile eşleşiyorsa bu makaleyi okuyun:

  • İş yükünüz, tam Azure bölge hatasına karşı olağanüstü durum kurtarma koruması gerektirir.
  • Kullanıcılara birden çok coğrafyada hizmet vermeniz ve ağ gecikme süresini en aza indirmeniz gerekir.
  • Mevzuat veya uyumluluk gereksinimleri, verilerin belirli coğrafi sınırlar içinde kalmasını zorunlu hale getirmektedir.
  • İş sürekliliği hedefleriniz, tek bir bölgenin kendi başına karşılayamayacağı bir kurtarma süresi hedefi (RTO) tanımlar.

İş yükünüz tek bir bölgede çalıştırılıyorsa ve alanlar arası yedekli dağıtımlar kullanılabilirlik gereksinimlerinizi karşılıyorsa, henüz çok bölgeli bir tasarıma ihtiyacınız olmayabilir. Merkez-uç topolojisiyle başlayın veya bir bölgede Sanal WAN ve daha sonra genişletin.

Lift-and-shift odaklı yaklaşım: Eski iş yükleri genellikle bölgeler arasında active-active çalışamaz. Tam etkin-etkin tasarım yerine kurtarma bölgesinde Azure Site Recovery ve hub ile olağanüstü durum kurtarma planlayın.

Modernleştirme odağı: Müşteriye yönelik uygulamaları, bölge yedekli SKU'lar kullanarak iki bölgede etkin-etkin olarak dağıtın ve gerektiğinde bölgeler arasında eşleme kurulabilmesi için çakışmayan adres alanı kullanın.

Bulutlar arası odak: Birden çok bölge ve dal arasında bağlantı kurmak ve bulutlar arası geçişinizle birlikte bölgeler arası yönlendirmeyi planlamak için Azure Sanal WAN kullanın.

Azure hizmetleri ve özellikleri

Aşağıdaki tabloda, çok bölgeli ağı etkinleştiren Azure hizmetleri ve özellikleri listelenmektedir:

Hizmet veya özellik Çok bölgeli tasarımdaki rol Daha fazla bilgi edinin
Azure Traffic Manager Herhangi bir protokol için bölgeler arasında DNS tabanlı trafik yönlendirme Traffic Manager'a genel bakış
Azure Front Door (Azure Ön Kapı hizmeti) Uçta CDN ve WAF ile HTTP/HTTPS genel yük dengeleme Front Door'a genel bakış
Küresel VNet Eşlemesi Farklı bölgelerdeki sanal ağlar arasında özel, yüksek bant genişliğine sahip bağlantı Sanal ağ eşleme
ExpressRoute Global Reach hakkında şirket içi siteleri Azure omurgası üzerinden birbirine bağlar ExpressRoute Global Reach hakkında
Azure Sanal WAN (çoklu hub) Otomatik merkezler arası yönlendirmeye sahip Microsoft tarafından yönetilen küresel transit Sanal WAN küresel geçiş
Azure Sanal Ağ Yöneticisi (AVNM) Bölgeler arası eşleme topolojisini ve ağ grubu yönetimini otomatikleştirir AVNM'ye genel bakış

Çoklu bölge için neden birden çok sanal ağ gerekir?

Sanal ağ (VNet) tek bir bölgeye yayılmıştır. Bu sanal ağın içindeki alt ağlar bölgedeki tüm kullanılabilirlik alanlarına yayılmıştır, ancak sanal ağın kendisi bölge sınırları boyunca genişletemez. Bu nedenle çoklu bölge ağı, bölge başına bir veya daha fazla sanal ağ dağıtmak ve bunları bölgeler arası hizmetlere bağlamak anlamına gelir.

Azure Front Door ve WAF'ın genel giriş trafiğini Batı Avrupa ve Doğu ABD bölgelerine yönlendirdiği, her birinde Azure Güvenlik Duvarı ve Azure Bastion içeren bir merkez VNet'in, bir iş yükü spoke VNet'i ile eşlendiği ve iki bölgenin Microsoft omurgası üzerinden Küresel VNet Eşlemesi ile birbirine bağlandığı iki bölgeli etkin-etkin topolojiyi gösteren diyagram.

Bu temel kısıtlama her çok bölgeli tasarımı şekillendirir:

  • Her bölgenin kendine ait bir VNet adres alanı olması gerekir (eşleme için diğer bölgelerle çakışmayan).
  • Bölgeler arası trafik için açık bir bağlantı mekanizması gerekir: Genel Sanal Ağ Eşlemesi, Sanal WAN merkezler arası veya ağ geçidi tabanlı yönlendirme.
  • Genel yük dengeleme hizmetleri (Traffic Manager veya Front Door) kullanıcıları doğru bölgesel dağıtıma yönlendirir.

Alt ağ ve adres planlama yönergeleri için bkz. IP adresi planlaması.

Kullanılabilirlik alanları ile bölgesel yedeklilik karşılaştırması

Çoklu bölge topolojisi tasarlamadan önce, Azure'daki iki altyapı yedekliliği düzeyini anlayın:

Level Karşı korur Mekanizma Example
Kullanılabilirlik alanları Bir bölge içinde tek veri merkezi hatası Bağımsız güç, soğutma ve ağ ile veri merkezlerini fiziksel olarak ayırın Alanlar arası yedekli Azure Güvenlik Duvarı 3 bölgeye dağıtıldı
Bölgesel yedeklilik Tam bölge hatası (doğal afet, yaygın kesinti) İş yüklerini iki veya daha fazla Azure bölgede dağıtma Doğu ABD ve Batı ABD bölgelerindeki aktif-aktif web uygulaması

Alanlar arası yedeklilik ile başlayın. Alanlar arası yedekli dağıtımlar, çok bölgeli yönlendirmenin karmaşıklığı olmadan en yaygın hata senaryolarına (tek veri merkezi sorunları) karşı koruma sağlar. İşletmeniz bölge genelindeki kesintilere karşı koruma gerektirdiğinde veya coğrafi olarak dağıtılmış kullanıcılara hizmet vermeniz gerektiğinde bölgesel yedeklilik ekleyin.

Bölge yedekli ağ hizmetleri başvurusu

Aşağıdaki tabloda çekirdek ağ hizmetleri için alanlar arası yedekli dağıtım seçenekleri gösterilmektedir. Bunları iş yüklerini çalıştırdığınız her bölgeye dağıtın:

Service Bölge yedekli seçenek Notlar
Azure Güvenlik Duvarı Kullanılabilirlik alanları arasında dağıtma Bölgedeki 3 bölgeye de dağıtılır
Standart Yük Dengeleyici Bölge yedekli ön uç Standart SKU için varsayılan davranış
Application Gateway v2 Alanlar arası yedekli dağıtım Standard_v2 veya WAF_v2 SKU gerektirir
VPN Ağ Geçidi Bölge yedekli SKU'larla aktif-aktif AZ son ekli SKU'ları kullanın (VpnGw1AZ, VpnGw2AZ vb.)
ExpressRoute Ağ Geçidi Bölge yedekli SKU'lar ErGw1AZ, ErGw2AZ veya ErGw3AZ kullanma
Azure Bastion Bölge yedekli (önizleme) Temel, Standart ve Premium SKU'lar
NAT Ağ Geçidi (StandardV2) Bölgesel olarak yedekli StandardV2 SKU gereklidir; Standart SKU yalnızca bölgeseldir

Bölgeler arası trafik yönlendirme yaklaşımı nasıl seçilir

Bölgeler arasında trafiği yönlendirmek için doğru hizmeti seçmek için aşağıdaki karar tablosunu kullanın:

Gereksiniminiz Önerilen hizmet Nasıl çalışır?
Herhangi bir protokol için çok bölgeli yük devretme veya yük dağıtımı (HTTP, TCP, UDP) Azure Traffic Manager DNS çözümlemesi aracılığıyla en iyi uç nokta IP'sini döndürür. İstemci doğrudan uç noktaya bağlanır. Yük devralma hızı DNS TTL değerine bağlıdır (genellikle 30–300 saniye).
CDN, WAF ve hızlı yük devretme ile genel HTTP/HTTPS yük dengeleme Azure Front Door (Azure Ön Kapı hizmeti) Bağlantıları uç varlık noktalarında (PoP'lerde) sonlandırır. İstekleri en yakın sağlıklı arka uca yönlendirir. Bağlantı düzeyinde yük devretme sağlar (DNS TTL’ye bağlı olmadan, saniyeler içinde).
Bölgeler arasındaki özel arka uç trafiği (çoğaltma, iç API'ler) Küresel VNet Eşlemesi VNets'i bölgeler arasında Microsoft omurga ağı üzerinden bağlar. Peering geçişli değildir; her peering ilişkisi açıkça tanımlanır. Per-GB veri aktarımı ücretleri uygulanır.
Azure aracılığıyla şirket içi siteden siteye bağlantı ExpressRoute Global Reach hakkında Şirket içi konumların merkez yönlendiricileri dolaşmadan Microsoft omurga üzerinden iletişim kurması için iki ExpressRoute bağlantı hattını bağlar.

İpucu

Bu hizmetleri birleştirin. Örneğin, kullanıcıya yönelik HTTP trafiği için Front Door'u ve bölgeler arasında arka uç replikasyonu için Genel VNet Eşlemesi'ni kullanın.

Çoklu bölge merkez topolojisi seçme

Ağınızı bölgeler arasında genişletmeye karar verdikten sonra bölgeler arası bağlantıyı yönetmek için bir merkez deseni seçin:

Faktör Bölge başına merkez (geleneksel) Sanal WAN birden çok hub’lı
Bölgeler arası bağlantı Müşteri, bölgesel hub’lar arasında Küresel VNet Eşleme yapılandırır ve UDR’leri yönetir Otomatik merkezler arası yönlendirme: tüm Sanal WAN hub'ları varsayılan olarak birbirine bağlanır
Management Yönlendirme, güvenlik duvarı kuralları ve eşleme üzerinde tam müşteri denetimi İlke tabanlı yönetime sahip Microsoft tarafından yönetilen hub altyapısı
En iyi kullanım alanları Ayrıntılı yönlendirme denetimine, özel NVA'lara veya mevcut merkez yatırımlarına ihtiyaç duyan kuruluşlar Birçok bölge, 30'den fazla dal sitesi veya yönetilen altyapı tercihi olan kuruluşlar
Genel geçiş Her hub çifti arasında açık eşleme + UDR yapılandırması gerektirir Yerleşik: herhangi iki hub arasındaki trafik otomatik olarak yönlendirilir
Scaling Hub'ları ve eşlemeleri manuel olarak ekleyin (AVNM otomatikleştirebilir) Sanal WAN yapılandırması aracılığıyla hub ekleme: güncelleştirmeleri otomatik olarak yönlendirme
Maliyet modeli Merkez sanal ağ kaynakları (güvenlik duvarı, ağ geçidi, eşleme) ayrı olarak faturalandırılır Sanal WAN birim fiyatlandırması artı bağlı kaynaklar

Merkez-uç ile tek bir bölgedeki Sanal WAN karşılaştırması için bkz. Merkez-uç topolojisi ve Sanal WAN.

Tasarımla ilgili dikkat edilecek noktalar

Lift-and-shift çok bölgeli tasarım odağı

  • Erişilebilirlik alanlarına veya bölgelere yayılamayan eski iş yükleri için, tasarımı aktif-aktif yerine olağanüstü durum kurtarmaya göre yapın: Azure Site Recovery kullanarak bir kurtarma bölgesine çoğaltın.
  • Kurtarma bölgesinde, yük devretme trafiğinin aynı paylaşılan hizmetlere sahip olması için birincil hub'ı yansıtan bir hub oluşturun.
  • Bölgesel bir kesinti sırasında kullanıcıları yeniden yönlendirmek için Azure Traffic Manager veya DNS yük devretmesini kullanın.
  • Yük devretme sırasında ve daha sonra yapılacak herhangi bir eşlemede çakışmaları önlemek için, kurtarma bölgesinin adres alanını birincil bölgeninkiyle örtüşmeyecek şekilde tutun.

Çok bölgeli tasarım odağını modernleştirme

  • En yüksek dayanıklılık düzeyi için, müşteriye dönük iş yüklerini bölge yedekli SKU’larla iki bölgede aktif-aktif olarak dağıtın.
  • Etkin-etkin uç ağların daha sonra yeniden adresleme yapmadan genel VNet eşlemesini kullanabilmesi için birincil ve yedek bölgelere çakışmayan adres aralıkları atayın.
  • Uygulama türüne göre teslim katmanınızı seçin: web uygulamaları için Azure Front Door ve web dışı uygulamalar için Traffic Manager, bölgesel genel uç noktalar arasında dağıtılıyor.
  • Gelen trafiğin arka uçlara ulaşmadan önce denetlenmesi için her bölgenin genel uç noktalarının önüne merkez güvenlik duvarını (SNAT ve DNAT) yerleştirin.

Bulutlar arası çok bölgeli tasarım odağı

  • Birden çok Azure bölgesini, dalını ve bulut kenarını otomatik olarak herhangi bir yönlendirmeyle birbirine bağlamak için Azure Sanal WAN kullanın.
  • Geçiş yönlendirmenin basit kalması için bölgeler ve bulutlar arasında özetlenmiş, çakışmayan adres aralıklarını planlayın.
  • Bölgesel güvenli hub'larda bulutlar arası IPsec bağlantılarını sonlandırın ve Sanal WAN merkezler arası yönlendirmeyi işlemesine izin verin.
  • Front Door veya Traffic Manager'ı kullanarak genel girişi bölgeler arasında dağıtıp her bölgesel merkez güvenlik duvarını incelemeye devam edin.

Prerequisites

Çoklu bölge ağı tasarlamadan önce şunları yaptığınızdan emin olun:

  • Tek bölgeli bir topoloji kuruldu ve test edildi. Merkez ve uç topolojisi veya Sanal WAN ile başlayın.
  • Tanımlanmış yüksek kullanılabilirlik ve olağanüstü durum kurtarma gereksinimleri: RTO, kurtarma noktası hedefi (RPO) ve uyumluluk gereksinimleri.
  • Tüm bölgelerde çakışmayan bir IP adresi planı oluşturuldu. Bkz. IP adresi planlama.
  • Hangi iş yüklerinin yalnızca bölgesel yedekliliğe ve bölge yedekliliğine ihtiyacı olduğunu belirledik.

Etkin-etkin ve aktif-pasif dağıtım desenleri karşılaştırması

Çok bölgeli dağıtım modeliniz normal çalışma sırasında ve bölgesel bir hata sırasında trafiğin nasıl aktığını belirler:

Active-active

Her iki bölge de aynı anda trafiğe hizmet sunmaktadır. Traffic Manager veya Front Door gibi genel bir yük dengeleyici, istekleri yakınlık, performans veya ağırlığa göre bölgeler arasında dağıtır.

Active-active ne zaman kullanılır:

  • Uygulamanız bölgeye özgü durum bağımlılıkları olmadan herhangi bir bölgedeki istekleri işleyebilir.
  • Mümkün olan en düşük RTO'ya ihtiyacınız var (sağlıklı bölge zaten trafiği karşıladığından yük devretme hemen gerçekleşir).
  • Normal çalışma sırasında her iki bölgede de kapasite kullanmak istiyorsunuz (maliyet verimliliği).

Ağ konusunda dikkat edilmesi gerekenler:

  • Her iki bölgenin de güvenlik duvarları, ağ geçitleri ve yük dengeleyiciler dahil olmak üzere aynı ağ altyapısına sahip olması gerekir.
  • Bölgeler arasındaki veri çoğaltması her iki dağıtımı da güncel tutmalıdır.
  • DNS TTL ve sistem durumu yoklama aralıkları, Traffic Manager'ın trafiği ne kadar hızlı kaydırdığını belirler. Front Door, bağlantı düzeyinde daha hızlı yük devretme sağlar.

Active-passive

Bir bölge (birincil) tüm trafiği işler. İkincil bölge hazır kalır ancak bir yük devretme olayına kadar kullanıcı isteklerine hizmet vermez.

Aktif-pasif ne zaman kullanılır:

  • Uygulamanızın katı yazma bölgesi gereksinimleri vardır veya durumu kolayca çoğaltamaz.
  • Maliyet kısıtlamaları iki bölgede aynı anda tam kapasite çalıştırılmasını engeller.
  • RTO toleransınız, ikincil bölgeyi etkinleştirmek için gereken süreyi sağlar.

Ağ konusunda dikkat edilmesi gerekenler:

  • Pasif bölgenin ağ altyapısı, failover gerçekleşene kadar daha düşük katmanlar ya da daha düşük kapasiteyle çalışabilir.
  • Otomatik yük devretme, uygun eşik değerlerine sahip sağlık denetimlerini gerektirir (kararsız geçişlerden kaçının).
  • Yük devretmeyi düzenli olarak test edin. Pasif bölgedeki ağ yapılandırmaları doğrulanmadıysa kayabilir.
  • Yönlendirme tablolarını ve NSG kurallarını bölgeler arasında eşzamanlı tutun. Pasif bölgenin birincil bölgenin güvenlik duruşuyla eşleştiğinden emin olmak için kod olarak altyapı şablonlarını kullanın.
  • Pasif bölgede VPN veya ExpressRoute ağ geçitlerinin ön sağlamasını yapın. Ağ geçidi sağlama 20-45 dakika sürebilir. Bu, çoğu RTO hedefi için fazla yavaştır.

Aktif-aktif ve aktif-pasif ağ yapıları arasında seçim yapmak

Etkin-etkin ve aktif-pasif ağ arasındaki seçim ağ boyutlandırmasını, maliyeti ve operasyonel karmaşıklığı etkiler:

Consideration Active-active Active-passive
Ağ kapasitesi Her iki bölgede de tam kapasite Pasif bölgede daha az kapasite (yük devretmeye göre ölçeklendirme)
Ağ geçidi sağlama Her iki bölgede de her zaman açık Önceden sağlanmış ancak daha küçük katmanlar kullanabilir
Bölgeler arası veri eşitleme Sürekli, çift yönlü çoğaltma trafiği Beklemeye tek yönlü zaman uyumsuz çoğaltma
Güvenlik duvarı kuralları Her ikisinde de aktif olarak uygulanan özdeş kural kümeleri Aynı kural kümeleri, ancak pasif küme nadiren kullanılır
IP adresleme Her iki bölge de genel yük dengeleyiciye tanıtılır Yük devretme gerçekleşene kadar yalnızca birincil bölge duyuru yapar
Operasyon riski Düşük: her iki yol da sürekli olarak test edilir Daha yüksek: Pasif yol kayabilir veya test edilmemiş yapılandırmalara sahip olabilir

Veri çoğaltma ve gecikme süresi

Bölgeler arası çoğaltma, uygulama tasarımını etkileyen ağ gecikme süresine neden olabilir. Aynı coğrafyadaki Azure bölgeler genellikle yakındaki çiftler için 1-10 ms gidiş dönüş gecikme süresi (örneğin Doğu ABD'den Doğu ABD 2'ye) ve uzak çiftler için 30-70 ms (örneğin Doğu ABD'den Batı ABD'ye) gösterir. Transatlantik veya transpacific bölge çiftleri 100 ms'yi aşabilir.

Önemli tasarım konuları:

  • Çoğaltma topolojisi: Yalnızca düşük gecikme süresine (< 10 ms) sahip bölge çiftleri için zaman uyumlu çoğaltmayı seçin. Uygulama performansının düşmesini önlemek için uzak çiftlerde eşzamansız çoğaltma kullanın.
  • Bant genişliği planlaması: Çoğaltma aktarım hızı gereksinimlerini tahmin edin ve GB başına Genel Sanal Ağ Eşlemesi veri aktarımı maliyetlerini hesaplayın. Uzak bölgeler arasındaki yüksek hacimli replikasyon, önemli veri çıkış ücretlerine neden olabilir.
  • Çakışma çözümü: Çift yönlü yazma işlemlerine sahip etkin-etkin desenler, uygulama veya veritabanı katmanında çakışma çözümleme stratejileri gerektirir. Ağ bağlantı sağlar, ancak uygulamaların yazma çakışmalarını işlemesi gerekir.
  • PaaS çoğaltması için özel uç noktalar: bölgeler arasında Azure SQL, Cosmos DB veya Depolama'yı çoğaltırken, çoğaltma trafiğini Microsoft omurgasında tutmak ve genel İnternet'e maruz kalmamak için her bölgedeki özel uç noktaları kullanın.

Maliyetle ilgili konular

Çok bölgeli ağ, yinelenen altyapı ve bölgeler arası veri aktarımı sayesinde maliyetleri artırır. Bütçenizi şu birincil maliyet etmenleri etrafında planlayın:

  • Bölgeler arası veri aktarımı: Küresel Sanal Ağ Eşlemesi ve Sanal WAN merkezler arası trafik, bölge sınırlarını aşan veriler için GB başına ücretlendirilir. Aynı bölgedeki eşlenen sanal ağlar arasındaki bölge içi trafik, aynı bölge için ek ücret alınmaz ve bölgeler arası için daha düşük bir oranda ücretlendirilir.
  • Çoğaltılmış ağ cihazları: Her bölge için ayrı güvenlik duvarı, yük dengeleyici ve ağ geçidi örnekleri gerekir. Etkin-etkin dağıtımlar bu maliyetleri ikiye katlar. Etkin-pasif dağıtımlar, bekleme bölgesinde daha küçük katmanlar kullanarak ve yük devretme sırasında ölçeği artırarak maliyetleri azaltabilir.
  • Genel yük dengeleme ücretleri: Hem Traffic Manager hem de Front Door, işlenen DNS sorgularına veya isteklerine göre ücretlendirilir. Front Door, uç PoP'lardan arka uçlara veri aktarımı için ayrıca ücret alır.
  • ExpressRoute ve VPN Gateway: Çok bölgeli tasarımlar genellikle her bölgede ağ geçidi örnekleri gerektirir. Birden fazla bölgeye bağlanan ExpressRoute bağlantı hatları aylık bağlantı noktası ücretleri ve GB başına tarifeli veri ücretleri ekler.
  • Trafik yerelliği ile iyileştirme: Bölgeler arası çağrıları en aza indirmek için uygulama katmanları tasarla. Çoğaltma bant genişliğini ve gecikmeye duyarlı sorguları azaltmak için okuma amaçlı çoğaltmaları her bölgede işlemle birlikte konumlandırın.

Güvenlik konuları

Çok bölgeli bir ağ, tek bölgeli dağıtımların ötesinde güvenlikle ilgili dikkat edilmesi gerekenler sağlar:

  • Trafik Microsoft omurgasında kalır. Küresel VNet Eşlemesi veya Sanal WAN merkezleri arası bağlantı üzerinden gerçekleşen tüm bölgeler arası trafik, genel internet yerine Microsoft omurga ağını kullanır.
  • Alanlar arası yedekli güvenlik duvarlarını her bölgeye dağıtın. Her bölgesel hub'ın trafik denetimi için kendi güvenlik duvarı örneğine ihtiyacı vardır. Bölge hataları sırasında güvenliği korumak için güvenlik duvarlarını kullanılabilirlik alanları arasında dağıtın.
  • Front Door WAF uç güvenliği sağlar. Front Door’u kullandığınızda, yerleşik Web Uygulaması Güvenlik Duvarı trafiği, bölgesel dağıtımlardan herhangi birine ulaşmadan önce inceler. Bu, ağ kenarında ilk savunma katmanını sağlar.
  • DNS yük devretmeyi dikkatle planlayın. Traffic Manager yük devri DNS TTL değerine bağlıdır. Daha kısa TTL'ler daha hızlı yük devretmeyi sağlar ancak DNS sorgu hacmini artırır. Front Door, istemci DNS önbelleği süresinin dolmasına bağlı olmayan bağlantı düzeyinde yük devretme sağlar.
  • ExpressRoute Global Reach trafiği özel kalır. Global Reach üzerinden bağlanan şirket içi siteler arasındaki trafik hiçbir zaman genel İnternet'e dokunmaz. Devreler arasındaki Microsoft omurgada kalır.
  • Bölgeler arası çoğaltma kanallarının güvenliğini sağlama. Global VNet Eşlemesi üzerinden geçen arka uç replikasyon trafiği varsayılan olarak özeldir, ancak aktarım halindeki hassas veriler için ağ güvenlik grupları ve şifreleme uygulayın.

Çoklu bölge tasarımınız bu kılavuzun başka bir yerinde ele alınan belirli senaryoları içeriyorsa bkz:

Daha fazla bilgi edinin

Bu makalede ele alınan hizmetler ve kavramlar hakkında daha fazla bilgi için aşağıdaki kaynaklara bakın:

Sonraki Adımlar

İpucu

Kendi başınıza mı keşfedersiniz? Özelliğe göre bir sonraki makalenizi bulmak için genel bakış gezginine dönün.

Lift-and-shift yolculuğunuzdaki bir sonraki adım:

Şirket içi ağınıza bağlanma: Olağanüstü durum kurtarmayı planladıktan sonra şirket içi vpn veya ExpressRoute bağlantısı kurun.

Modernleştirme yolculuğunuzda bir sonraki adım:

İnternet giriş desenlerinizi tasarlama: Müşteri trafiğinin birincil ve yedekleme bölgelerinizde uygulamalarınıza nasıl ulaştığını belirleyin.

Bulutlar arası yolculuğunuzda sonraki adım:

Diğer bulutlarınıza şifreli tüneller ayarlayın: Çoklu bölge planlaması yaptıktan sonra bulutlar arası VPN bağlantısını yapılandırın.

  • Last updated on