Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Az ExpressRoute magas rendelkezésre állásra lett tervezve, hogy szolgáltatói szintű magánhálózati kapcsolatot biztosítson a 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-kapcsolatcsoportok rendelkezésre állásának maximalizálására vonatkozó tervezési szempontokért lásd : Magas rendelkezésre állás tervezése az ExpressRoute és a Well-Architectured Framework használatával
Azonban, ha figyelembe vesszük Murphy népszerű mondását-- ha valami elromolhat, el is romlik--, ebben a cikkben koncentráljunk azokra a megoldásokra, amelyek túlmutatnak azon hibákon, amelyeket egyetlen ExpressRoute áramkörrel lehet kezelni. Áttekintjük a hálózati architektúra szempontjait, hogy a georedundáns ExpressRoute-kapcsolatcsoportok használatával robusztus háttérhálózati kapcsolatot építsünk ki vészhelyreállításhoz.
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
Vannak olyan esetek és lehetőségek, amikor az ExpressRoute kapcsolódási pontok vagy egy teljes regionális szolgáltatás minősége romlik. Az ilyen regionális szintű szolgáltatáskimaradás alapvető oka a természetes katasztrófa. Ezért fontos megtervezni a vészhelyreállítást az üzletmenet-folytonosság és a kritikus fontosságú alkalmazások érdeké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:
- Használjon helyek közötti VPN-t biztonsági másolatként a privát társviszony-létesítési forgalomhoz.
- Használja az internetkapcsolatot vészhelyzeti megoldásként a Microsoft peering forgalmához.
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ással foglalkoznak:
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.
Ebben a cikkben bemutatjuk, hogyan lehet kezelni a georedundáns útvonalak konfigurálása során felmerülő kihívásokat.
Kis és közepes helyszíni hálózati szempontok
Tekintsük át 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 az előnyben részesített útvonalat jelöli (az ExpressRoute 1-en keresztül), a pontozott pedig az egymástól független útvonalat (az ExpressRoute 2-n keresztül).
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-kapcsolatcsoportok esetében azonban figyelembe kell vennünk a különböző hálózati teljesítményeket különböző hálózati útvonalakkal (különösen a hálózati késés esetén). 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).
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.
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.
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.
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 (Autonomous System) elérési út 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. Ebben a szakaszban bemutatjuk, hogyan tervezhet vészhelyreállítást az aktív-aktív ExpressRoute-kapcsolatcsoportok használatával anélkül, hogy további készenléti áramkörökre lenne szükség.
Tekintsük át az alábbi ábrán látható példát. A példában a Contoso két helyszínen kapcsolódik két Contoso IaaS-üzembe helyezéshez két különböző Azure-régióban ExpressRoute-kapcsolatokon keresztül két különböző kapcsolódási helyen.
A katasztrófa utáni helyreállítás tervezése hatással van arra, hogyan történik a forgalomirányítás a régiók és helyek között (régió1/régió2 és hely2/hely1). Tekintsünk két különböző 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 tervezzük meg a vészhelyreállítást, hogy az Azure-régió és a helyszíni hálózat közötti összes forgalom állandó állapotban haladjon át a helyi ExpressRoute-kapcsolatcsoporton. Ha a helyi ExpressRoute-kapcsolatcsoport meghibásodik, a rendszer a távoli ExpressRoute-kapcsolatcsoportot használja az Azure és a helyszíni hálózat közötti összes forgalomhoz.
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.
A forgatókönyvet kapcsolati súly használatával alakíthatja ki, hogy befolyásolja a virtuális hálózatokat, hogy a helyi peering helyére történő csatlakozást részesítse előnyben, az ExpressRoute-ot használva a helyszíni hálózathoz kötött forgalom esetében. A megoldás elvégzéséhez gondoskodnia kell a szimmetrikus fordított forgalomról. Ön a helyi preferencia konfiguráció használatával adhat meg egy előnyben részesített ExpressRoute-kapcsolatot az iBGP-munkamenetben, amely az Ön BGP útválasztói között zajlik (ezeken az ExpressRoute-kapcsolatok a helyszíni oldalon végződnek). A megoldást az alábbi ábrán szemlélteti.
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 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 előpend (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. Az Azure-hoz kötött forgalom helyszíni hálózati útvonalválasztásának befolyásolásához a helyszíni hely közötti összekapcsolást kevésbé előnyösebbnek 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).
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.
Következő lépések
Ebben a cikkben az ExpressRoute áramkör privát peering kapcsolatának vészhelyreállításának tervezésével foglalkoztunk. 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ással foglalkoznak: