ExpressRoute özel eşlemesi ile olağanüstü durum kurtarma için tasarlama

  • Makale

ExpressRoute, Microsoft kaynaklarına operatör sınıfı özel ağ bağlantısı sağlamak üzere yüksek kullanılabilirlik için tasarlanmıştır. Başka bir deyişle, Microsoft ağı içindeki ExpressRoute yolunda tek bir hata noktası yoktur. ExpressRoute bağlantı hattının kullanılabilirliğini en üst düzeye çıkarmaya yönelik tasarım konuları için bkz . ExpressRoute ve İyi Mimarili Çerçeve ile yüksek kullanılabilirlik için tasarlama

Ancak, Murphy'nin popüler reklamını (herhangi bir sorun olabilirse) göz önünde bulundurarak, bu makalede tek bir ExpressRoute bağlantı hattı kullanılarak giderilebilen hataların ötesine geçebilecek çözümlere odaklanmamıza olanak sağlar. Coğrafi olarak yedekli ExpressRoute bağlantı hatlarını kullanarak olağanüstü durum kurtarma için sağlam bir arka uç ağ bağlantısı oluşturmaya yönelik ağ mimarisiyle ilgili önemli noktaları inceleyeceğiz.

Dekont

Bu makalede açıklanan kavramlar, Sanal WAN altında veya dışında bir ExpressRoute bağlantı hattı oluşturulduğunda aynı şekilde geçerlidir.

Yedekli bağlantı çözümü gerekiyor

ExpressRoute eşleme konumlarının veya tüm bölgesel hizmetin düşürüldüğü olasılıklar ve örnekler vardır. Bu tür bölgesel geniş hizmet kesintilerinin temel nedeni doğal felakettir. Bu nedenle, iş sürekliliği ve görev açısından kritik uygulamalar için olağanüstü durum kurtarmayı planlamak önemlidir.

Dekont

Doğal afet sırasında iş sürekliliğini korumak gibi zamana duyarlı bir durumda olağanüstü durum kurtarma tasarımı uygulamanız gerektiğinde aşağıdaki faktörleri dikkate almanız gerekir:

  • Bu belge, farklı eşleme konumları aracılığıyla yapılandırılan birden çok ExpressRoute bağlantı hattı için güçlü bir olağanüstü durum kurtarma tasarımının nasıl uygulandığını gösteren yönergeler sağlar. Bu senaryoda ExpressRoute bağlantı hatlarını ayarlamak için yeterli zaman ve kaynağa sahip olduğunuz varsayılır.
  • Coğrafi olarak yedekli olmayan tek bir ExpressRoute bağlantı hattı için hızlı bir şekilde olağanüstü durum kurtarma tasarımı yapılandırmanız gerekiyorsa, aşağıdaki alternatifleri kullanabilirsiniz:

Ne olursa olsun, görev açısından kritik uygulamalarınızı bir Azure bölgesinde, şirket içinde veya başka bir yerde çalıştırdığınızda, yük devretme siteniz olarak başka bir Azure bölgesini kullanabilirsiniz. Aşağıdaki makaleler uygulamalardan ve ön uç erişim perspektiflerinden olağanüstü durum kurtarmayı ele alır:

Şirket içi ağınızla Microsoft arasında ExpressRoute bağlantısına güveniyorsanız, ExpressRoute üzerinden olağanüstü durum kurtarmayı planlamak için aşağıdakileri göz önünde bulundurmanız gerekir:

  • coğrafi olarak yedekli ExpressRoute bağlantı hatlarını kullanma
  • farklı ExpressRoute bağlantı hattı için farklı hizmet sağlayıcı ağlarını kullanma
  • ExpressRoute bağlantı hattının her birini yüksek kullanılabilirlik için tasarlama
  • farklı ExpressRoute bağlantı hattını müşteri ağında farklı bir konumda sonlandırma
  • Kullanılabilirlik alanı kullanan ExpressRoute Sanal Ağ Ağ Geçitlerini kullanma

Birden çok ExpressRoute bağlantı hattı kullanmanın zorlukları

Aynı ağ kümesini birden fazla bağlantı kullanarak birbirine bağladığınızda, ağlar arasında paralel yollar eklersiniz. Paralel yollar, düzgün bir şekilde tasarlanmadığında asimetrik yönlendirmeye yol açabilir. Yolda bir NAT veya güvenlik duvarı gibi durum bilgisi olan varlıklarınız varsa, asimetrik yönlendirme trafik akışını engelleyebilir. Genellikle ExpressRoute özel eşleme yolu üzerinden NAT veya Güvenlik Duvarları gibi durum bilgisi olan varlıklarla karşılaşmazsınız. Bu nedenle ExpressRoute özel eşlemesi üzerinden asimetrik yönlendirmenin trafik akışını engellemesi şart değildir.

Ancak coğrafi olarak yedekli paralel yollarda trafiğin yükünü dengelerseniz, durum bilgisi olan varlıklarınız olup olmadığına bakılmaksızın tutarsız ağ performansıyla karşılaşırsınız. Bu coğrafi olarak yedekli paralel yollar, konum sayfasına göre sağlayıcılarda bulunan aynı metro veya farklı metro üzerinden olabilir.

Aynı metroda ExpressRoute devreleri ile yedeklilik

Birçok metronun iki ExpressRoute konumu vardır. Amsterdam ve Amsterdam2 buna bir örnek olabilir. Yedeklilik tasarlarken, aynı metroda her iki konumda da Azure'a iki paralel yol oluşturabilirsiniz. Bu görevi aynı sağlayıcıyla gerçekleştirir veya dayanıklılığı artırmak için farklı bir hizmet sağlayıcısıyla çalışmayı seçersiniz. Bu tasarımın bir diğer avantajı da uygulama yük devretmesi gerçekleştiğinde şirket içi uygulamalarınız ile Microsoft arasındaki uçtan uca gecikme süresinin yaklaşık olarak aynı kalmasıdır. Ancak deprem gibi doğal bir afet varsa her iki yol için de bağlantı artık kullanılamayabilir.

Farklı metrolardaki ExpressRoute bağlantı hatlarıyla yedeklilik

Yedeklilik için farklı metrolar kullanırken, aynı jeo-politik bölgede ikincil konumu seçmeniz gerekir. Coğrafi politik bölgenin dışında bir konum seçmek için, paralel yollardaki her iki bağlantı hattı için de Premium SKU kullanmanız gerekir. Bu yapılandırmanın avantajı, her iki bağlantıda da kesintiye neden olan doğal bir olağanüstü durum olasılığının daha düşük olmasıdır, ancak gecikme süresinin uçtan uca artmasına neden olur.

Dekont

ExpressRoute bağlantı hatlarında BFD'nin etkinleştirilmesi, Microsoft Enterprise Edge (MSEE) cihazları ile Müşteri/İş Ortağı Edge yönlendiricileri arasında daha hızlı bağlantı hatası algılamaya yardımcı olur. Ancak, yedekli siteye genel yük devretme ve yakınsama, bazı hata koşullarında 180 saniyeye kadar sürebilir ve bu süre boyunca gecikme süresi veya performans düşüşü artabilir.

Bu makalede, coğrafi olarak yedekli yolları yapılandırırken karşılaşabileceğiniz zorlukların nasıl ele alınabileceğini ele alalım.

Küçük ve orta ölçekli şirket içi ağ konuları

Aşağıdaki diyagramda gösterilen örnek ağı ele alalım. Örnekte, contoso'nun şirket içi konumu ile Contoso'nun Azure bölgesindeki sanal ağı arasında coğrafi olarak yedekli ExpressRoute bağlantısı kurulur. Diyagramda düz mavi çizgi tercih edilen yolu (ExpressRoute 1 aracılığıyla) ve noktalı çizgi ise (ExpressRoute 2 aracılığıyla) stand-by yolunu temsil eder.

Diagram of small to medium size on-premises network considerations.

Varsayılan olarak, yolları tüm ExpressRoute yollarında aynı şekilde tanıtıyorsanız Azure, eşit maliyetli çok yollu (ECMP) yönlendirmeyi kullanarak şirket içi bağlı trafiği tüm ExpressRoute yollarında dengeler.

Ancak coğrafi olarak yedekli ExpressRoute bağlantı hatları ile farklı ağ yollarına sahip farklı ağ performanslarını dikkate almalıyız (özellikle ağ gecikme süresi için). Normal çalışma sırasında daha tutarlı bir ağ performansı elde etmek için minimum gecikme süresi sunan ExpressRoute bağlantı hattını tercih edebilirsiniz.

Aşağıdaki tekniklerden birini (etkinlik sırasına göre listelenmiştir) kullanarak Azure'ı bir ExpressRoute devresini başka bir ExpressRoute bağlantı hattına tercih edecek şekilde etkileyebilirsiniz:

  • diğer ExpressRoute bağlantı hatlarına kıyasla tercih edilen ExpressRoute bağlantı hattı üzerinden daha belirli bir rotanın reklamını yapmak
  • sanal ağı tercih edilen ExpressRoute bağlantı hattına bağlayan bağlantıda daha yüksek Bağlan ion Weight yapılandırması
  • yolları daha uzun AS Yolu ile daha az tercih edilen ExpressRoute bağlantı hattı üzerinden tanıtma (AS Path prepend)

Daha belirli bir yol

Aşağıdaki diyagramda, daha belirli bir yol tanıtımı kullanılarak ExpressRoute yol seçiminin nasıl etkilenmesi gösterilmektedir. Gösterilen örnekte Contoso şirket içi /24 IP aralığı, tercih edilen yol (ExpressRoute 1) aracılığıyla iki /25 adres aralığı olarak ve stand-by yolu (ExpressRoute 2) aracılığıyla /24 olarak tanıtılır.

Diagram of influencing path selection using more specific routes.

/25, /24 ile karşılaştırıldığında daha belirgin olduğundan, Azure 10.1.11.0/24'e yönelik trafiği normal durumda ExpressRoute 1 aracılığıyla gönderir. ExpressRoute 1'in her iki bağlantısı da kapanırsa sanal ağ yalnızca ExpressRoute 2 aracılığıyla 10.1.11.0/24 yol tanıtımını görür; ve bu nedenle bekleme devresi bu hata durumunda kullanılır.

Bağlan ion ağırlığı

Aşağıdaki ekran görüntüsünde, Azure portalı aracılığıyla ExpressRoute bağlantısının ağırlığını yapılandırma gösterilmektedir.

Screenshot of configuring connection weight via Azure portal.

Aşağıdaki diyagramda bağlantı ağırlığı kullanılarak ExpressRoute yolu seçiminin nasıl etkilenmesi gösterilmektedir. Varsayılan bağlantı ağırlığı 0'dır. Aşağıdaki örnekte ExpressRoute 1 bağlantısının ağırlığı 100 olarak yapılandırılmıştır. Bir sanal ağ, birden fazla ExpressRoute bağlantı hattı aracılığıyla tanıtılan bir yol ön eki aldığında, sanal ağ en yüksek ağırlığa sahip bağlantıyı tercih eder.

Diagram of influencing path selection using connection weight.

ExpressRoute 1'in her iki bağlantısı da kapanırsa sanal ağ yalnızca ExpressRoute 2 aracılığıyla 10.1.11.0/24 yol tanıtımını görür; ve bu nedenle bekleme devresi bu hata durumunda kullanılır.

AS yolu önceden ekli

Aşağıdaki diyagramda, önceden ekli AS yolu kullanılarak ExpressRoute yolu seçiminin nasıl etkilenmiş olduğu gösterilmektedir. Diyagramda ExpressRoute 1 üzerinden yol tanıtımı, eBGP'nin varsayılan davranışını gösterir. ExpressRoute 2 üzerinden yol tanıtımında, şirket içi ağın ASN'sinin ek olarak yolun AS yoluna eklenmesi gerekir. Aynı yol birden çok ExpressRoute bağlantı hattı üzerinden alındığında, eBGP yol seçimi işlemine göre, sanal ağ en kısa AS yoluna sahip yolu tercih eder.

Diagram of influencing path selection using AS path prepend.

ExpressRoute 1'in her iki bağlantısı da kapanırsa sanal ağ yalnızca ExpressRoute 2 aracılığıyla 10.1.11.0/24 yol tanıtımını görür. Sonuç olarak, daha uzun AS yolu ilgisiz hale gelir. Bu nedenle, bekleme devresi bu hata durumunda kullanılır.

Tekniklerden herhangi birini kullanarak Azure'ı ExpressRoute'unuzdan birini diğerlerine tercih edecek şekilde etkilerseniz, asimetrik akışlardan kaçınmak için şirket içi ağın da Azure'a bağlı trafik için aynı ExpressRoute yolunu tercih etmesini sağlamanız gerekir. Genellikle yerel tercih değeri, şirket içi ağın bir ExpressRoute bağlantı hattını diğerlerine göre tercih etmelerini sağlamak için kullanılır. Yerel tercih bir iç BGP (iBGP) ölçümüdür. En yüksek yerel tercih değerine sahip BGP yolu tercih edilir.

Önemli

Belirli ExpressRoute bağlantı hatlarını hazırda bekleme olarak kullandığınızda, bunları etkin bir şekilde yönetmeniz ve yük devretme işlemini düzenli aralıklarla test etmeniz gerekir.

Büyük dağıtılmış kurumsal ağ

Büyük bir dağıtılmış kurumsal ağınız varsa, büyük olasılıkla birden çok ExpressRoute bağlantı hattınız vardır. Bu bölümde, başka bir stand-by bağlantı hattına gerek kalmadan etkin-etkin ExpressRoute bağlantı hatlarını kullanarak olağanüstü durum kurtarma tasarlamayı görelim.

Aşağıdaki diyagramda gösterilen örneği ele alalım. Örnekte Contoso'nun iki farklı eşleme konumundaki ExpressRoute bağlantı hatları aracılığıyla iki farklı Azure bölgesinde iki Contoso IaaS dağıtımına bağlı iki şirket içi konumu vardır.

Diagram of large distributed on-premises network considerations.

Olağanüstü durum kurtarmanın mimarisini oluşturma şeklimiz, bölgeler arası konumlar arası (bölge1/bölge2 ile konum2/konum1) trafiğinin nasıl yönlendirilmiş olduğunu etkiler. Bölgeler arası konum trafiğini farklı şekilde yönlendiren iki farklı olağanüstü durum mimarisini ele alalım.

1. Senaryo

İlk senaryoda, bir Azure bölgesi ile şirket içi ağ arasındaki tüm trafiğin yerel ExpressRoute bağlantı hattı üzerinden sabit durumda akması için olağanüstü durum kurtarma tasarlayalım. Yerel ExpressRoute bağlantı hattı başarısız olursa, Azure ile şirket içi ağ arasındaki tüm trafik akışları için uzak ExpressRoute bağlantı hattı kullanılır.

Senaryo 1 aşağıdaki diyagramda gösterilmiştir. Diyagramda yeşil çizgiler, VNet1 ile şirket içi ağlar arasındaki trafik akışının yollarını gösterir. Mavi çizgiler, VNet2 ile şirket içi ağlar arasındaki trafik akışının yollarını gösterir. Düz çizgiler sabit durumda istenen yolu, kesikli çizgiler ise sabit durumlu trafik akışı taşıyan ilgili ExpressRoute bağlantı hattının başarısız olması durumunda trafik yolunu gösterir.

Diagram of traffic flow for first scenario.

Sanal ağları şirket içi ağa bağlı trafik için yerel eşleme konumu ExpressRoute'a bağlantıyı tercih etmeye etkilemek için bağlantı kalınlığını kullanarak senaryonun mimarisini oluşturabilirsiniz. Çözümü tamamlamak için simetrik ters trafik akışından emin olmanız gerekir. ExpressRoute bağlantı hattını tercih etmek için BGP yönlendiricileriniz (şirket içi tarafında ExpressRoute devrelerinin sonlandırıldığı) arasındaki iBGP oturumunda yerel tercihi kullanabilirsiniz. Çözüm aşağıdaki diyagramda gösterilmiştir.

Diagram of active-active ExpressRoute circuits solution 1.

2. Senaryo

Senaryo 2 aşağıdaki diyagramda gösterilmiştir. Diyagramda yeşil çizgiler, VNet1 ile şirket içi ağlar arasındaki trafik akışının yollarını gösterir. Mavi çizgiler, VNet2 ile şirket içi ağlar arasındaki trafik akışının yollarını gösterir. Diyagramdaki sabit ve düz çizgilerde, sanal ağlar ve şirket içi konumlar arasındaki tüm trafik normal olarak Microsoft omurgasını kullanarak akar ve yalnızca hata durumundaki şirket içi konumlar arasındaki bağlantı üzerinden akar; diyagramdaki noktalı çizgiler ve ExpressRoute'un.

Diagram of traffic flow for second scenario.

Çözüm aşağıdaki diyagramda gösterilmiştir. Gösterildiği gibi, sanal ağ yolu seçimini etkilemek için senaryonun mimarisini daha belirli bir yol (Seçenek 1) veya AS-path prepend (Seçenek 2) kullanarak oluşturabilirsiniz. Azure'a bağlı trafik için şirket içi ağ yolu seçimini etkilemek için, şirket içi konum arasındaki bağlantıyı daha az tercih edilir olarak yapılandırmanız gerekir. Ara bağlantı bağlantısını tercih edilir olarak yapılandırma şekliniz, şirket içi ağda kullanılan yönlendirme protokolüne bağlıdır. iBGP ile yerel tercihi veya IGP ile ölçüm (OSPF veya IS-IS) kullanabilirsiniz.

Diagram of active-active ExpressRoute circuits solution 2.

Önemli

Bir veya birden çok ExpressRoute bağlantı hattı birden çok sanal ağa bağlandığında, sanal ağdan sanal ağa trafik ExpressRoute aracılığıyla yönlendirilebilir. Ancak, bu önerilmez. Sanal ağdan sanal ağa bağlantıyı etkinleştirmek için sanal ağ eşlemesini yapılandırın.

Sonraki adımlar

Bu makalede, ExpressRoute bağlantı hattı özel eşleme bağlantısını olağanüstü durum kurtarma için tasarlamayı ele aldık. Aşağıdaki makaleler uygulamalardan ve ön uç erişim perspektiflerinden olağanüstü durum kurtarmayı ele alır: