ExpressRoute özel eşlemesi ile olağanüstü durum kurtarma için tasarlamaDesigning for disaster recovery with ExpressRoute private peering

ExpressRoute, Microsoft kaynaklarına yönelik taşıyıcı sınıfı özel ağ bağlantısı sağlamak için yüksek kullanılabilirlik için tasarlanmıştır.ExpressRoute is designed for high availability to provide carrier grade private network connectivity to Microsoft resources. Diğer bir deyişle, Microsoft ağı içindeki ExpressRoute yolunda tek bir hata noktası yoktur.In other words, there is no single point of failure in the ExpressRoute path within Microsoft network. ExpressRoute devresinin kullanılabilirliğini en üst düzeye çıkarmak için tasarım konuları için bkz. ExpressRoute ile yüksek kullanılabilirlik Için tasarlama.For design considerations to maximize the availability of an ExpressRoute circuit, see Designing for high availability with ExpressRoute.

Bununla birlikte, Murphy 'in popüler AdAge 'yi almakiçin bir şey yanlış gidecekse, bu makalede tek bir ExpressRoute bağlantı hattı kullanılarak ele alınan hatalardan çok daha fazla geçen çözümlere odaklanalım.However, taking Murphy's popular adage--if anything can go wrong, it will--into consideration, in this article let us focus on solutions that go beyond failures that can be addressed using a single ExpressRoute circuit. Bu makalede, diğer bir deyişle, coğrafi olarak yedekli ExpressRoute devreleri kullanarak olağanüstü durum kurtarma için sağlam arka uç ağ bağlantısı oluşturmaya yönelik ağ mimarisi konularına bakmamıza izin verir.In other words, in this article let us look into network architecture considerations for building robust backend network connectivity for disaster recovery using geo-redundant ExpressRoute circuits.

Yedekli bağlantı çözümü gerekiyorNeed for redundant connectivity solution

Bölgesel bir hizmetin tamamının (Microsoft, ağ hizmeti sağlayıcıları, müşteri veya diğer bulut hizmeti sağlayıcılarının) düştüğü durumlar ve örnekler vardır.There are possibilities and instances where an entire regional service (be it that of Microsoft, network service providers, customer, or other cloud service providers) gets degraded. Bu bölgesel çapta hizmet etkisinin temel nedeni, doğal Calamity içerir.The root cause for such regional wide service impact include natural calamity. Bu nedenle, iş sürekliliği ve görev açısından kritik uygulamalar için olağanüstü durum kurtarma planlamanız önemlidir.Therefore, for business continuity and mission critical applications it is important to plan for disaster recovery.

Görev açısından kritik uygulamalarınızı bir Azure bölgesinde veya şirket içinde ya da başka herhangi bir yerde çalıştırıp çalıştırmadığına bakılmaksızın, yük devretme siteniz olarak başka bir Azure bölgesi de kullanabilirsiniz.Irrespective of whether you run your mission critical applications in an Azure region or on-premises or anywhere else, you can use another Azure region as your failover site. Aşağıdaki makalelerde uygulamalardan ve ön uç erişim perspektiflerinden olağanüstü durum kurtarma ele alınmaktadır:The following articles addresses disaster recovery from applications and frontend access perspectives:

Şirket içi ağınız ile Microsoft iş açısından kritik işlemler için ExpressRoute bağlantısına sahipseniz, olağanüstü durum kurtarma planınız de coğrafi olarak yedekli ağ bağlantısı içermelidir.If you rely on ExpressRoute connectivity between your on-premises network and Microsoft for mission critical operations, your disaster recovery plan should also include geo-redundant network connectivity.

Birden çok ExpressRoute devreleri kullanma sorunlarıChallenges of using multiple ExpressRoute circuits

Birden fazla bağlantı kullanarak aynı ağ kümesini birbirine gönderdiğinizde, ağlar arasında paralel yollar ortaya çıkarabilir.When you interconnect the same set of networks using more than one connection, you introduce parallel paths between the networks. Paralel yollar düzgün şekilde uygun olmadığında, asymmetrik yönlendirmeye yol açabilir.Parallel paths, when not properly architected, could lead to asymmetrical routing. Yolda durum bilgisi olan varlıklara (örneğin NAT, güvenlik duvarı) sahipseniz, asymmetrik yönlendirme trafik akışını engelleyebilir.If you have stateful entities (for example, NAT, firewall) in the path, asymmetrical routing could block traffic flow. Genellikle, ExpressRoute özel eşleme yolu üzerinden NAT veya güvenlik duvarları gibi durum bilgisi olan varlıkların üzerinden gelmezsiniz.Typically, over the ExpressRoute private peering path you won't come across stateful entities such as NAT or Firewalls. Bu nedenle, ExpressRoute özel eşlemesi üzerinden asymmetrik yönlendirme trafik akışını engellemez.Therefore, asymmetrical routing over ExpressRoute private peering does not necessarily block traffic flow.

Bununla birlikte, coğrafi olarak yedekli paralel yollar arasında trafiği dengeleyebiliyorsanız, durum bilgisi olan varlıklara sahip olup olmadıklarına bakılmaksızın tutarsız ağ performansı yaşayabilirsiniz.However, if you load balance traffic across geo-redundant parallel paths, irrespective of whether you have stateful entities or not, you would experience inconsistent network performance. Bu makalede, bu zorluk sorunlarını nasıl ele vertiğimizden bahsedelim.In this article, let's discuss how to address these challenges.

Küçük ve orta ölçekli şirket içi ağ konularıSmall to medium on-premises network considerations

Aşağıdaki diyagramda gösterilen örnek ağı ele alalım.Let's consider the example network illustrated in the following diagram. Örnekte, bir Azure bölgesindeki contoso şirket içi konumu ve contoso VNet arasında coğrafi olarak yedekli ExpressRoute bağlantısı oluşturulur.In the example, geo-redundant ExpressRoute connectivity is established between a Contoso's on-premises location and Contoso's VNet in an Azure region. Diyagramda, düz yeşil çizgi tercih edilen yolu (ExpressRoute 1 aracılığıyla) gösterir ve noktalı bir tek yolu (ExpressRoute 2 aracılığıyla) temsil eder.In the diagram, solid green line indicates preferred path (via ExpressRoute 1) and the dotted one represents stand-by path (via ExpressRoute 2).

11

Olağanüstü durum kurtarma için ExpressRoute bağlantısı tasarlarken şunları göz önünde bulundurmanız gerekir:When you are designing ExpressRoute connectivity for disaster recovery, you need to consider:

  • coğrafi olarak yedekli ExpressRoute devreleri kullanmausing geo-redundant ExpressRoute circuits
  • farklı ExpressRoute devresi için farklı hizmet sağlayıcı ağı kullanmausing diverse service provider network(s) for different ExpressRoute circuit
  • yüksek kullanılabilirlik Için ExpressRoute devresinin her birini tasarlamadesigning each of the ExpressRoute circuit for high availability
  • farklı ExpressRoute devresini müşteri ağında farklı bir yerde sonlandırmaterminating the different ExpressRoute circuit in different location on the customer network

Varsayılan olarak, yolları tüm ExpressRoute yollarında aynı şekilde tanıdıysanız, Azure, eşit maliyetli çoklu yol (ECMP) yönlendirmesi kullanarak tüm ExpressRoute yollarında şirket içi bağlı trafiği yük dengelemeye çalışır.By default, if you advertise routes identically over all the ExpressRoute paths, Azure will load-balance on-premises bound traffic across all the ExpressRoute paths using Equal-cost multi-path (ECMP) routing.

Ancak, coğrafi olarak yedekli ExpressRoute devreleri, farklı ağ yollarına sahip farklı ağ performanslarını (özellikle ağ gecikmesi için) dikkate almamız gerekir.However, with the geo-redundant ExpressRoute circuits we need to take into consideration different network performances with different network paths (particularly for network latency). Normal işlem sırasında daha tutarlı ağ performansı almak için, en düşük gecikme süresini sunan ExpressRoute devresini tercih etmek isteyebilirsiniz.To get more consistent network performance during normal operation, you may want to prefer the ExpressRoute circuit that offers the minimal latency.

Aşağıdaki tekniklerden birini kullanarak bir ExpressRoute devresini tercih etmek üzere Azure 'u etkileyebilir (verimlilik sırasıyla listelenmiştir):You can influence Azure to prefer one ExpressRoute circuit over another one using one of the following techniques (listed in the order of effectiveness):

  • diğer ExpressRoute bağlantı hatlarına kıyasla tercih edilen ExpressRoute bağlantı hattı üzerinden daha fazla özel yol duyuruyoradvertising more specific route over the preferred ExpressRoute circuit compared to other ExpressRoute circuit(s)
  • sanal ağı tercih edilen ExpressRoute devresine bağlayan bağlantıda daha yüksek bağlantı ağırlığı yapılandırmaconfiguring higher Connection Weight on the connection that links the virtual network to the preferred ExpressRoute circuit
  • Yol olarak daha uzun tercih edilen ExpressRoute bağlantı hattı üzerinden yolları bildirme (yol Prepend olarak)advertising the routes over less preferred ExpressRoute circuit with longer AS Path (AS Path prepend)

Daha belirgin yolMore specific route

Aşağıdaki diyagramda, daha belirgin yol tanıtımı kullanılarak ExpressRoute yol seçiminin etkili bir şekilde kullanılması gösterilmektedir.The following diagram illustrates influencing ExpressRoute path selection using more specific route advertisement. Gösterilen örnekte, contoso şirket içi/24 IP aralığı, tercih edilen yol (ExpressRoute 1) aracılığıyla iki/25 adres aralığı ve tek yönlü yol (ExpressRoute 2) aracılığıyla/24 olarak tanıtıldığında.In the illustrated example, Contoso on-premises /24 IP range is advertised as two /25 address ranges via the preferred path (ExpressRoute 1) and as /24 via the stand-by path (ExpressRoute 2).

[![iki]][2][![2]][2]

/25,/24 ile karşılaştırıldığında daha belirgin olduğundan, Azure, 10.1.11.0/24 ' e gidecek trafiği normal durumda ExpressRoute 1 üzerinden gönderir.Because /25 is more specific, compared to /24, Azure would send the traffic destined to 10.1.11.0/24 via ExpressRoute 1 in the normal state. ExpressRoute 1 bağlantılarının her ikisi de kapalıysa, VNet 10.1.11.0/24 yol tanıtımını yalnızca ExpressRoute 2 aracılığıyla görebilir; Bu nedenle, bu hata durumunda bekleme devresi kullanılır.If both the connections of ExpressRoute 1 go down, then the VNet would see the 10.1.11.0/24 route advertisement only via ExpressRoute 2; and therefore the standby circuit is used in this failure state.

Bağlantı ağırlığıConnection weight

Aşağıdaki ekran görüntüsünde, Azure portal aracılığıyla bir ExpressRoute bağlantısının ağırlığını yapılandırma gösterilmektedir.The following screenshot illustrates configuring the weight of an ExpressRoute connection via Azure portal.

[![03]][3][![3]][3]

Aşağıdaki diyagramda bağlantı ağırlığı kullanılarak ExpressRoute yol seçiminin etkili bir şekilde kullanılması gösterilmektedir.The following diagram illustrates influencing ExpressRoute path selection using connection weight. Varsayılan bağlantı ağırlığı 0 ' dır.The default connection weight is 0. Aşağıdaki örnekte, ExpressRoute 1 bağlantısının ağırlığı 100 olarak yapılandırılır.In the example below, the weight of the connection for ExpressRoute 1 is configured as 100. VNet birden fazla ExpressRoute bağlantı hattı üzerinden tanıtılan bir rota önekini aldığında, VNet en yüksek ağırlığa sahip bağlantıyı tercih eder.When a VNet receives a route prefix advertised via more than one ExpressRoute circuit, the VNet will prefer the connection with the highest weight.

[![4]][4][![4]][4]

ExpressRoute 1 bağlantılarının her ikisi de kapalıysa, VNet 10.1.11.0/24 yol tanıtımını yalnızca ExpressRoute 2 aracılığıyla görebilir; Bu nedenle, bu hata durumunda bekleme devresi kullanılır.If both the connections of ExpressRoute 1 go down, then the VNet would see the 10.1.11.0/24 route advertisement only via ExpressRoute 2; and therefore the standby circuit is used in this failure state.

AS yolu önüneAS path prepend

Aşağıdaki diyagramda yol Prepend 'i kullanarak ExpressRoute yol seçiminin etkili bir şekılde kullanılması gösterilmektedir.The following diagram illustrates influencing ExpressRoute path selection using AS path prepend. Diyagramda, ExpressRoute 1 üzerinden yönlendirme tanıtımı, eBGP 'nin varsayılan davranışını gösterir.In the diagram, the route advertisement over ExpressRoute 1 indicates the default behavior of eBGP. ExpressRoute 2 üzerinden rota tanıtımına, şirket içi ağın ASN 'si de yolun AS yolunda ek olarak sona erer.On the route advertisement over ExpressRoute 2, the on-premises network's ASN is prepended additionally on the route's AS path. Aynı yol birden çok ExpressRoute bağlantı hattı aracılığıyla alındığında, eBGP yol seçimi işlemi başına, VNet en kısa AS yolunu içeren yolu tercih eder.When the same route is received through multiple ExpressRoute circuits, per the eBGP route selection process, VNet would prefer the route with the shortest AS path.

[![e]][5][![5]][5]

ExpressRoute 1 bağlantılarının her ikisi de kapalıysa, VNet 10.1.11.0/24 yol tanıtımını yalnızca ExpressRoute 2 aracılığıyla görebilir.If both the connections of ExpressRoute 1 go down, then the VNet would see the 10.1.11.0/24 route advertisement only via ExpressRoute 2. Yani, daha uzun olan yol, ilgisiz hale gelir.Consequentially, the longer AS path would become irrelevant. Bu nedenle, bekleme devresi bu hata durumunda kullanılır.Therefore, the standby circuit would be used in this failure state.

Azure 'u başka bir şekilde kullanarak ExpressRoute 'tan birini tercih edebilirsiniz. Ayrıca, asimetrik akışlardan kaçınmak için şirket içi ağın aynı ExpressRoute yolunu da tercih etmeniz gerekir.Using any of the techniques, if you influence Azure to prefer one of your ExpressRoute over others, you also need to ensure the on-premises network also prefer the same ExpressRoute path for Azure bound traffic to avoid asymmetric flows. Genellikle, yerel tercih değeri, şirket içi ağı diğer bir ExpressRoute devresini tercih etmek üzere etkilemek için kullanılır.Typically, local preference value is used to influence on-premises network to prefer one ExpressRoute circuit over others. Yerel tercih bir iç BGP (iBGP) ölçümdür.Local preference is an internal BGP (iBGP) metric. En yüksek yerel tercih değerine sahip BGP rotası tercih edilir.The BGP route with the highest local preference value is preferred.

Önemli

Belirli ExpressRoute devrelerini tek başına kullandığınızda, bunları etkin bir şekilde yönetmeniz ve düzenli aralıklarla yük devretme işlemini test etmeniz gerekir.When you use certain ExpressRoute circuits as stand-by, you need to actively manage them and periodically test failover operation.

Büyük dağıtılmış kurumsal ağLarge distributed enterprise network

Büyük bir dağıtılmış kurumsal ağınız olduğunda, muhtemelen birden fazla ExpressRoute devreniz vardır.When you have a large distributed enterprise network, you're likely to have multiple ExpressRoute circuits. Bu bölümde, etkin-etkin ExpressRoute devreleri kullanarak olağanüstü durum kurtarmanın nasıl tasarlanacağını, ek tek başına devrelere gerek duymadan görelim.In this section, let's see how to design disaster recovery using the active-active ExpressRoute circuits, without needing additional stand-by circuits.

Aşağıdaki diyagramda gösterilen örneği ele alalım.Let's consider the example illustrated in the following diagram. Örnekte, contoso iki farklı eşleme konumunda ExpressRoute devreleri aracılığıyla iki farklı Azure bölgesinde iki adet contoso IaaS dağıtımına bağlı iki şirket içi konum vardır.In the example, Contoso has two on-premises locations connected to two Contoso IaaS deployment in two different Azure regions via ExpressRoute circuits in two different peering locations.

[![inç]][6][![6]][6]

Olağanüstü durum kurtarmanın nasıl mimarilerimiz, çapraz konuma çapraz konum (region1/Region2 to Location2/location1) trafiğinin nasıl yönlendirildiğini etkiler.How we architect the disaster recovery has an impact on how cross regional to cross location (region1/region2 to location2/location1) traffic is routed. Çapraz bölge konumu trafiğini farklı yollarla yönlendiren iki farklı olağanüstü durum mimarilerine göz atalım.Let's consider two different disaster architectures that routes cross region-location traffic differently.

Senaryo 1Scenario 1

İlk senaryoda, bir Azure bölgesi ve şirket içi ağ arasındaki tüm trafiğin, sabit durumdaki yerel ExpressRoute bağlantı hattı üzerinden akışı gibi olağanüstü durum kurtarma tasarlayalim.In the first scenario, let's design disaster recovery such that all the traffic between an Azure region and on-premises network flow through the local ExpressRoute circuit in the steady state. 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 devresi kullanılır.If the local ExpressRoute circuit fails, then the remote ExpressRoute circuit is used for all the traffic flows between Azure and on-premises network.

Aşağıdaki diyagramda Senaryo 1 gösterilmektedir.Scenario 1 is illustrated in the following diagram. Diyagramda yeşil çizgiler, VNet1 ve şirket içi ağlar arasındaki trafik akışı için yolları gösterir.In the diagram, green lines indicate paths for traffic flow between VNet1 and on-premises networks. Mavi çizgiler, VNet2 ve şirket içi ağlar arasındaki trafik akışı için yolları gösterir.The blue lines indicate paths for traffic flow between VNet2 and on-premises networks. Kesintisiz satırlarda, istenen yol kararlı durumda ve kesik çizgili satırlarda, sabit durum trafik akışını taşıyan ilgili ExpressRoute bağlantı hattının başarısız olduğu trafik yolunu gösterir.Solid lines indicate desired path in the steady-state and the dashed lines indicate traffic path in the failure of the corresponding ExpressRoute circuit that carries steady-state traffic flow.

[![7@@]][7][![7]][7]

Şirket içi ağa bağlı trafik için yerel eşleme konumu ExpressRoute 'a bağlantıyı tercih etmek üzere sanal ağları etkilemek için bağlantı ağırlığı kullanarak senaryoyu mimARDA dağıtabilirsiniz.You can architect the scenario using connection weight to influence VNets to prefer connection to local peering location ExpressRoute for on-premises network bound traffic. Çözümü tamamlayabilmeniz için, simetrik trafik akışının tersine çevrilmiş olduğundan emin olmanız gerekir.To complete the solution, you need to ensure symmetrical reverse traffic flow. Bir ExpressRoute devresini tercih etmek için BGP yönlendiricileriniz (Şirket içi tarafında ExpressRoute devrelerinin sonlandırıldığı) arasında IGP oturumunda yerel tercihi kullanabilirsiniz.You can use local preference on the iBGP session between your BGP routers (on which ExpressRoute circuits are terminated on on-premises side) to prefer a ExpressRoute circuit. Çözüm aşağıdaki diyagramda gösterilmiştir.The solution is illustrated in the following diagram.

[![240]][8][![8]][8]

Senaryo 2Scenario 2

Senaryo 2 aşağıdaki diyagramda gösterilmiştir.The Scenario 2 is illustrated in the following diagram. Diyagramda yeşil çizgiler, VNet1 ve şirket içi ağlar arasındaki trafik akışı için yolları gösterir.In the diagram, green lines indicate paths for traffic flow between VNet1 and on-premises networks. Mavi çizgiler, VNet2 ve şirket içi ağlar arasındaki trafik akışı için yolları gösterir.The blue lines indicate paths for traffic flow between VNet2 and on-premises networks. Düzenli durumda (diyagramdaki düz satırlarda), sanal ağlar ve şirket içi konumlar arasındaki tüm trafik, en bölüm için Microsoft omurga aracılığıyla akar ve yalnızca hata durumundaki şirket içi konumlar arasındaki iç bağlantı üzerinden akar (içindeki noktalı çizgiler Diyagram) bir ExpressRoute.In the steady-state (solid lines in the diagram), all the traffic between VNets and on-premises locations flow via Microsoft backbone for the most part, and flows through the interconnection between on-premises locations only in the failure state (dotted lines in the diagram) of an ExpressRoute.

[![tuşlarına]][9][![9]][9]

Çözüm aşağıdaki diyagramda gösterilmiştir.The solution is illustrated in the following diagram. Gösterildiği gibi, VNET yol seçimini etkilemek için, daha belirgin yol (seçenek 1) veya as-Path önüne (seçenek 2) kullanarak senaryoyu mimARDA dağıtabilirsiniz.As illustrated, you can architect the scenario either using more specific route (Option 1) or AS-path prepend (Option 2) to influence VNet path selection. Azure bağlı trafiği için şirket içi ağ yolu seçimini etkilemek için, şirket içi konum arasındaki iç yönü daha az tercih edilen şekilde yapılandırmanız gerekir.To influence on-premises network route selection for Azure bound traffic, you need configure the interconnection between the on-premises location as less preferable. Bağlı olan bağlantıyı, şirket içi ağ içinde kullanılan yönlendirme protokolüne bağlı olarak tercih ettiğiniz şekilde yapılandırırsınız.Howe you configure the interconnection link as preferable depends on the routing protocol used within the on-premises network. Yerel tercihi IOP veya ölçümle (OSPF veya SIS) ile birlikte kullanabilirsiniz.You can use local preference with iBGP or metric with IGP (OSPF or IS-IS).

[![(]][10][![10]][10]

Sonraki adımlarNext steps

Bu makalede, bir ExpressRoute devresi özel eşleme bağlantısının olağanüstü durum kurtarma için nasıl tasarlanacağını tartıştık.In this article, we discussed how to design for disaster recovery of an ExpressRoute circuit private peering connectivity. Aşağıdaki makalelerde uygulamalardan ve ön uç erişim perspektiflerinden olağanüstü durum kurtarma ele alınmaktadır:The following articles addresses disaster recovery from applications and frontend access perspectives:

[2]: ./media/designing-for-disaster-recovery-with-expressroute-pvt/specificroute.png "daha belirgin yollar kullanarak yol seçimini etkili" bir şekilde seçme [3]: ./media/designing-for-disaster-recovery-with-expressroute-pvt/configure-weight.png "Azure Portal aracılığıyla bağlantı ağırlığını yapılandırma" [4]: ./media/designing-for-disaster-recovery-with-expressroute-pvt/connectionweight.png "bağlantı ağırlığı kullanarak yol seçimini" seçme [5]: ./media/designing-for-disaster-recovery-with-expressroute-pvt/aspath.png "yol sonuna kadar kullanılan yol seçimini" seçme [6]: ./media/designing-for-disaster-recovery-with-expressroute-pvt/multi-region.png "büyük dağıtılan şirket içi ağ konuları" [7]: ./media/designing-for-disaster-recovery-with-expressroute-pvt/multi-region-arch1.png "Senaryo 1" [8]: ./media/designing-for-disaster-recovery-with-expressroute-pvt/multi-region-sol1.png "etkin-etkin ExpressRoute bağlantı hattı çözümü 1" [9]: ./media/designing-for-disaster-recovery-with-expressroute-pvt/multi-region-arch2.png "Senaryo 2" [10]: ./media/designing-for-disaster-recovery-with-expressroute-pvt/multi-region-sol2.png "etkin-etkin ExpressRoute devre çözümü 2"