Katasztrófahelyzet utáni helyreállítás tervezése az ExpressRoute privát peeringgel

Az ExpressRoute magas rendelkezésre állásra lett tervezve, hogy szolgáltatói szintű magánhálózati kapcsolatot biztosítson Microsoft erőforrásokhoz. Más szóval a Microsoft-hálózaton belüli ExpressRoute-útvonalon nincs egyetlen meghibásodási pont sem. Az ExpressRoute-áramkör rendelkezésre állásának maximalizálásával kapcsolatos tervezési szempontokért tekintse meg a Tervezés magas rendelkezésre állásra az ExpressRoute használatával és a Well-Architected Framework című témaköröket.

Azonban Murphy népszerű szállóigéjét (ha valami elromolhat, el is fog romlani) figyelembe véve ez a cikk olyan megoldásokra összpontosít, amelyek túlmutatnak azokon a hibákon, amelyeket egyetlen ExpressRoute-kapcsolat kezelni tud. Megvizsgálja a hálózati architektúra szempontjait a georedundáns ExpressRoute-kapcsolatcsoportok használatával történő vészhelyreállításhoz szükséges robusztus háttérhálózati kapcsolatok kiépítéséhez.

Feljegyzés

A cikkben ismertetett fogalmak ugyanúgy érvényesek, ha egy ExpressRoute-kapcsolatcsoport a Virtual WAN alatt vagy azon kívül jön létre.

Redundáns kapcsolati megoldásra van szükség

Az ExpressRoute peeringhelyei vagy egy teljes regionális szolgáltatás teljesítménye romolhat. A regionális szintű szolgáltatáskimaradások közé tartozhat a természeti katasztrófa. Tervezze meg a vészhelyreállítást az üzletmenet-folytonosság és a kritikus fontosságú alkalmazások esetében.

Feljegyzés

Ha vészhelyreállítási tervet kell implementálnia egy időérzékeny helyzetben, például egy természeti katasztrófa során az üzletmenet folytonosságának fenntartása érdekében, a következő tényezőket kell figyelembe vennie:

  • Ez a dokumentum útmutatást nyújt a különböző társviszony-létesítési helyeken konfigurált több ExpressRoute-kapcsolatcsoport robusztus vészhelyreállítási tervének implementálásához. Ez a forgatókönyv feltételezi, hogy elegendő ideje és erőforrása van az ExpressRoute-kapcsolatcsoportok beállításához.
  • Ha gyorsan konfigurálnia kell egy vészhelyreállítási tervet egyetlen, nem georedundáns ExpressRoute-kapcsolatcsoporthoz, a következő alternatívákat használhatja:

Függetlenül attól, hogy a kritikus fontosságú alkalmazásokat egy Azure-régióban, a helyszínen vagy bárhol máshol futtatja, feladatátvételi helyként használhat egy másik Azure-régiót. Az alábbi cikkek az alkalmazások és az előtérbeli hozzáférés szempontjából történő vészhelyreállításról szólnak:

Ha a helyszíni hálózat és a Microsoft közötti ExpressRoute-kapcsolatra támaszkodik, az ExpressRoute-on keresztüli vészhelyreállítás megtervezéséhez az alábbiakat kell figyelembe vennie:

  • georedundáns ExpressRoute-kapcsolatcsoportok használata
  • különböző szolgáltatói hálózatok használata különböző ExpressRoute-kapcsolatcsoportokhoz
  • Az ExpressRoute áramkörök tervezése a magas rendelkezésre állás érdekében
  • a különböző ExpressRoute-kapcsolatcsoport megszakítása az ügyfélhálózat különböző helyén
  • a rendelkezésre állási zónával tisztában lévő ExpressRoute virtuális hálózati átjárók használata

Több ExpressRoute-kapcsolatcsoport használatának kihívásai

Ha ugyanazt a hálózatcsoportot több kapcsolattal is összekapcsolja, párhuzamos útvonalakat vezet be a hálózatok között. A párhuzamos útvonalak, ha nem megfelelően van megszerkesztettek, aszimmetrikus útválasztáshoz vezethetnek. Ha állapotalapú entitásokkal rendelkezik, például egy NAT vagy tűzfal az útvonalban, az aszimmetrikus útválasztás blokkolhatja a forgalom áramlását. Az ExpressRoute privát peering útvonalán általában nem találkozhat állapotalapú entitásokkal, mint például a NAT-ok vagy tűzfalak. Ezért az ExpressRoute privát peering-en keresztüli aszimmetrikus útválasztás nem feltétlenül akadályozza a forgalom áramlását.

Ha azonban a terheléselosztás georedundáns párhuzamos útvonalakon történik, függetlenül attól, hogy állapotalapú entitásokkal rendelkezik-e, inkonzisztens hálózati teljesítményt tapasztalhat. Ezek a georedundáns párhuzamos útvonalak ugyanazon a városon vagy különböző városokon keresztül haladhatnak, amelyeket a szolgáltatók hely szerinti oldalán található.

Redundancia ExpressRoute-kapcsolatcsoportokkal ugyanabban a metróban

Sok metró két ExpressRoute-hellyel rendelkezik. Ilyen például Amszterdam és Amszterdam2. A redundancia tervezésekor két párhuzamos útvonalat hozhat létre az Azure-ba, mindkét helyen ugyanabban a metróban. Ezt a feladatot ugyanazzal a szolgáltatóval hajtja végre, vagy másik szolgáltatóval dolgozik a rugalmasság javítása érdekében. Ennek a kialakításnak egy másik előnye, hogy amikor átváltás történik, a helyszíni alkalmazások és a Microsoft közötti végponttól végpontig terjedő késleltetés nagyjából azonos marad. Ha azonban természeti katasztrófa( például földrengés) következik be, előfordulhat, hogy mindkét útvonal kapcsolata már nem érhető el.

Redundancia ExpressRoute-hálózatokkal különböző városokban

Ha különböző metrókat használ a redundancia érdekében, válassza ki a másodlagos helyet ugyanabban a geopolitikai régióban. A földrajzi régión kívüli hely kiválasztásához prémium termékváltozatot kell használnia mindkét kapcsolatcsoporthoz a párhuzamos útvonalakon. Ennek a konfigurációnak az az előnye, hogy a mindkét kapcsolatnál kimaradásokat okozó természeti katasztrófa esélye alacsonyabb, de a végpontok közötti nagyobb késés árán.

Feljegyzés

Ha engedélyezi a BFD-t az ExpressRoute-kapcsolatcsoportokon, az segít a Microsoft Enterprise Edge (MSEE) eszközök és az Ügyfél/Partner Edge útválasztók közötti kapcsolati hibák gyorsabb észlelésében. A teljes feladatátvétel és a redundáns helyhez való konvergenciája azonban bizonyos meghibásodási feltételek mellett akár 180 másodpercet is igénybe vehet, és ez idő alatt megnövekedett késést vagy teljesítménycsökkenést tapasztalhat.

Az alábbi szakaszok a georedundáns útvonalak konfigurálása során felmerülő kihívásokra nyújtanak választ.

Kis és közepes helyszíni hálózati szempontok

Tekintse meg az alábbi ábrán látható példahálózatot. A példában georedundáns ExpressRoute-kapcsolat jön létre a Contoso helyszíni helye és a Contoso virtuális hálózata között egy Azure régióban. A diagramon az egyszínű kék vonal jelzi az előnyben részesített útvonalat (az ExpressRoute 1-en keresztül), a pontozott pedig az önálló útvonalat (az ExpressRoute 2-n keresztül).

Kis és közepes méretű helyszíni hálózati szempontok diagramja.

Alapértelmezés szerint, ha az útvonalakat az összes ExpressRoute-útvonalon azonos módon hirdeti meg, az Azure terheléselosztja a helyszíni kötött forgalmat legfeljebb 4 ExpressRoute-kapcsolatcsoporton egyenlő költségű többútvonalos (ECMP) útválasztással.

A georedundáns ExpressRoute-kapcsolatcsoportoknál azonban figyelembe kell vennie a különböző hálózati útvonalak eltérő hálózati teljesítményét, különösen a hálózati késést. A normál működés során konzisztensebb hálózati teljesítmény érdekében érdemes lehet a minimális késést kínáló ExpressRoute-kapcsolatcsoportot előnyben részesíteni.

Az Azure-t az alábbi technikák egyikével (a hatékonyság sorrendjében felsorolva) befolyásolhatja, hogy egy ExpressRoute-kapcsolatcsoportot előnyben részesítsen egy másikkal szemben:

  • pontosabb útvonal hirdetése az előnyben részesített ExpressRoute-kapcsolatcsoporton a többi ExpressRoute-kapcsolatcsoporthoz képest
  • nagyobb kapcsolati súly konfigurálása azon a kapcsolaton, amely a virtuális hálózatot az előnyben részesített ExpressRoute-kapcsolatcsoporthoz köti
  • az útvonalak meghirdetése a kevésbé előnyben részesített ExpressRoute-kapcsolaton hosszabb AS útvonallal (AS Path prepend)

Pontosabb útvonal

Az alábbi ábra az ExpressRoute útvonalválasztásának befolyásolását mutatja be pontosabb útvonalhirdetés használatával. Az ábrán látható példában a Contoso helyszíni /24 IP-címtartománya két /25 címtartományként van meghirdetve az előnyben részesített útvonalon (ExpressRoute 1) és /24-esként a készenléti útvonalon (ExpressRoute 2).

Diagram az útvonalválasztás konkrétabb útvonalak használatával történő befolyásolására.

Mivel a /25 pontosabb, a /24-hez képest az Azure az ExpressRoute 1-en keresztül a 10.1.11.0/24-be irányuló forgalmat normál állapotban küldené el. Ha az ExpressRoute 1 mindkét kapcsolata leáll, akkor a virtuális hálózat csak az ExpressRoute 2-n keresztül látja a 10.1.11.0/24-es útvonalhirdetést; ezért ebben a hibaállapotban a készenléti kapcsolatcsoportot használja a rendszer.

Kapcsolat súlya

Az alábbi képernyőkép egy ExpressRoute-kapcsolat súlyának az Azure Portalon keresztüli konfigurálását mutatja be.

Képernyőkép a kapcsolat súlyának az Azure Portalon keresztüli konfigurálásáról.

Az alábbi ábra az ExpressRoute-útvonal kiválasztásának a kapcsolat súlyával történő befolyásolását mutatja be. Az alapértelmezett kapcsolati súly 0. Az alábbi példában az ExpressRoute 1 kapcsolatának súlya 100-ként van konfigurálva. Ha egy virtuális hálózat egynél több ExpressRoute-kapcsolatcsoporton keresztül meghirdetett útvonalelőtagot kap, a virtuális hálózat a legnagyobb súlyú kapcsolatot részesíti előnyben.

Diagram az útvonal kiválasztásának a kapcsolat súlyával való befolyásolására.

Ha az ExpressRoute 1 mindkét kapcsolata leáll, akkor a virtuális hálózat csak az ExpressRoute 2-n keresztül látja a 10.1.11.0/24-es útvonalhirdetést; ezért ebben a hibaállapotban a készenléti kapcsolatcsoportot használja a rendszer.

AS útvonal előkészítés

Az alábbi ábra szemlélteti, hogyan lehet befolyásolni az ExpressRoute útvonal kiválasztását az AS elérési út előtoldásával. A diagramon az ExpressRoute 1 útvonalhirdetése az eBGP alapértelmezett viselkedését jelzi. Az ExpressRoute 2 útvonalhirdetésénél a helyszíni hálózat ASN-je hozzá van adva az útvonal AS-útvonalához. Ha ugyanazt az útvonalat több ExpressRoute-kapcsolatcsoporton keresztül fogadják, az eBGP útvonalválasztási folyamatának megfelelően a virtuális hálózat a legrövidebb AS útvonallal rendelkező útvonalat részesíti előnyben.

Diagram az útvonalválasztás befolyásolására az AS útvonal előtagolás használatával.

Ha az ExpressRoute 1 mindkét kapcsolata leáll, akkor a virtuális hálózat csak az ExpressRoute 2-n keresztül látja a 10.1.11.0/24-es útvonalhirdetést. Következésképpen a hosszabb AS útvonal irrelevánssá válik. Ezért ebben a hibaállapotban a készenléti kapcsolatcsoportot kell használni.

Ha bármelyik technikát használja, és az Azure-t az ExpressRoute egyikének előnyben részesítésére bírja a másikkal szemben, akkor biztosítania kell, hogy a helyi hálózat is ugyanazt az ExpressRoute-útvonalat részesítse előnyben az Azure felé irányuló forgalomhoz, hogy elkerülje az aszimmetrikus adatforgalmat. A helyi beállítási érték általában arra szolgál, hogy befolyásolja a helyszíni hálózatot, hogy egy ExpressRoute-kapcsolatcsoportot részesítsen előnyben másokkal szemben. A helyi preferencia egy belső BGP-metrika (iBGP). A legmagasabb helyi preferenciaértékkel rendelkező BGP-útvonal lesz előnyben.

Fontos

Ha bizonyos ExpressRoute-kapcsolatcsoportokat készenlétiként használ, aktívan kell kezelnie őket, és rendszeres időközönként tesztelnie kell a feladatátvételi műveletet.

Nagy méretű elosztott vállalati hálózat

Ha nagy méretű elosztott vállalati hálózattal rendelkezik, valószínűleg több ExpressRoute-kapcsolatcsoporttal rendelkezik. Ez a szakasz bemutatja, hogyan tervezhet vészhelyreállítást aktív-aktív ExpressRoute-kapcsolatcsoportok használatával anélkül, hogy másik készenléti kapcsolatcsoportra lenne szükség.

Tekintse meg az alábbi ábrán látható példát. A példában a Contoso két helyszíni telephellyel rendelkezik, amelyek két különböző Azure-régióban futó két Contoso IaaS-telepítéshez kapcsolódnak, ExpressRoute-kapcsolatcsoportokon keresztül, két különböző kapcsolódási helyen.

Nagyméretű elosztott helyszíni hálózati szempontok diagramja.

A vészhelyreállítás megtervezése hatással van arra, hogy a rendszer hogyan irányítja át a régiók közötti és a helyek közötti forgalmat (régió1/régió2–hely2/hely1). Vegyünk két vészarchitektúrát, amelyek eltérő módon irányítják a régiók közötti forgalmat.

Forgatókönyv 1

Az első forgatókönyvben úgy tervezi meg a vészhelyreállítást, hogy egy Azure-régió és a helyszíni hálózat közötti összes forgalom normál működés során a helyi ExpressRoute-áramkörön haladjon át. Ha a helyi ExpressRoute-kapcsolatcsoport meghibásodik, a távoli ExpressRoute-kapcsolatcsoport kezeli a Azure és a helyszíni hálózat közötti összes forgalmat.

Az 1. forgatókönyvet az alábbi diagram szemlélteti. Az ábrán a zöld vonalak a VNet1 és a helyszíni hálózatok közötti forgalom útvonalait jelölik. A kék vonalak a VNet2 és a helyszíni hálózatok közötti forgalom útvonalait jelölik. A folytonos vonalak a kívánt útvonalat jelzik az állandó állapotban, a szaggatott vonalak pedig a megfelelő ExpressRoute-kapcsolatcsoport meghibásodásának forgalmi útvonalát jelzik, amely állandó állapotú forgalmat bonyolít.

Az első forgatókönyv forgalmi folyamatának diagramja.

A forgatókönyv úgy alakítható ki, hogy a kapcsolatsúly használatával befolyásolja a virtuális hálózatokat (VNeteket), hogy a helyszíni hálózat felé irányuló forgalom esetén a helyi társviszony-létesítési ponthoz való ExpressRoute-kapcsolatot részesítsék előnyben. A megoldás elvégzéséhez gondoskodnia kell a szimmetrikus fordított forgalomról. A BGP-útválasztók közötti iBGP-munkamenetben (amelyen az ExpressRoute-kapcsolatcsoportok leállnak a helyszíni oldalon) helyi beállításokat használhat az ExpressRoute-kapcsolatcsoportok előnyben részesítéséhez. A megoldást az alábbi ábrán szemlélteti.

Az aktív-aktív ExpressRoute-kapcsolatcsoportok 1. megoldásának diagramja.

2. forgatókönyv

A 2. forgatókönyvet az alábbi diagram szemlélteti. Az ábrán a zöld vonalak a VNet1 és a helyszíni hálózatok közötti forgalom útvonalait jelölik. A kék vonalak a VNet2 és a helyszíni hálózatok közötti forgalom útvonalait jelölik. A diagram állandó állapotú, szilárd vonalai esetében a virtuális hálózatok és a helyszíni helyek közötti összes forgalom a Microsoft gerinchálózatának megfelelően folyik, és a helyszíni helyek közötti összekapcsoláson csak az ExpressRoute meghibásodási állapotában, a diagram pontozott vonalain halad át.

A második forgatókönyv forgalmi folyamatának diagramja.

A megoldást az alábbi ábrán szemlélteti. Az ábrán látható módon a forgatókönyvet konkrétabb útvonal (1. lehetőség) vagy as-path prepend (2. lehetőség) használatával alakíthatja ki a virtuális hálózati útvonal kiválasztásának befolyásolása érdekében. A helyszíni hálózati útvonalak Azure kötött forgalom kiválasztásának befolyásolásához a helyszíni hely közötti összekapcsolást a kevésbé előnyösebb módon kell konfigurálnia. Az összekapcsolási kapcsolat konfigurálása a helyszíni hálózaton használt útválasztási protokolltól függhet. Lokális preferenciát használhat az iBGP-vel vagy metrikát az IGP-vel (OSPF vagy IS-IS).

Az aktív-aktív ExpressRoute-kapcsolatcsoportok 2. megoldásának diagramja.

Fontos

Ha egy vagy több ExpressRoute-kapcsolatcsoport több virtuális hálózathoz csatlakozik, a virtuális hálózat és a virtuális hálózat közötti forgalom az ExpressRoute-on keresztül irányítható. Ez azonban nem ajánlott. A virtuális hálózatok közötti kapcsolódás engedélyezéséhez konfigurálja a virtuális hálózati társviszonyt.

Ez a cikk azt ismerteti, hogyan kell megtervezni az ExpressRoute-áramkör privát peeringkapcsolatának vészhelyreállítását. Az alábbi cikkek az alkalmazások és az előtérbeli hozzáférés szempontjából történő vészhelyreállításról szólnak: