Vészhelyreállítás tervezése
A Virtual WAN lehetővé teszi az összes globális üzemelő példány összesítését, csatlakoztatását, központi kezelését és védelmét. A globális üzemelő példányok különböző ágak, jelenléti pontok (PoP), magánfelhasználók, irodák, Azure-beli virtuális hálózatok és más többfelhős üzemelő példányok bármilyen kombinációját tartalmazhatják. Az SD-WAN, a helyek közötti VPN, a pont–hely VPN és az ExpressRoute használatával csatlakoztathatja a különböző helyeket egy virtuális központhoz. Ha több virtuális központtal rendelkezik, az összes központ teljes hálóban csatlakozna egy standard Virtual WAN-üzembe helyezéshez.
Ebből a cikkből megtudhatja, hogyan építhet ki különböző típusú, a Virtual WAN által a vészhelyreállításhoz támogatott hálózati kapcsolati lehetőségeket.
A Virtual WAN szolgáltatásként való hálózati csatlakozási lehetőségei
A Virtual WAN a következő háttérkapcsolati beállításokat támogatja:
- Távoli felhasználói kapcsolat
- Branch/Office/SD-WAN/Helyek közötti VPN
- Privát kapcsolat (ExpressRoute privát társviszony-létesítés)
Ezen csatlakozási lehetőségek mindegyikéhez a Virtual WAN külön átjárópéldányokat helyez üzembe egy virtuális központban.
A Virtual WAN eredetileg úgy lett kialakítva, hogy magas rendelkezésre állású hálózati összesítési megoldást kínáljon. A magas rendelkezésre állás érdekében a Virtual WAN több példányt is létrehoz, ha mindegyik ilyen típusú átjáró üzembe van helyezve egy Virtual WAN-központban. Az ExpressRoute magas rendelkezésre állásáról további információt az ExpressRoute-tal való magas rendelkezésre állás tervezése című témakörben talál.
A pont–hely VPN-átjáró esetében az üzembe helyezett példányok minimális száma kettő. A pont–hely VPN-átjáróval kiválaszthatja a pont–hely átjárók összesített átviteli sebességét, és a rendszer automatikusan kiépíti a több példányt. Az összesített kapacitást a virtuális központhoz csatlakozni kívánt ügyfelek vagy felhasználók száma alapján választhatja ki. Az ügyfélkapcsolat szempontjából a pont–hely VPN-átjárópéldányok az átjáró teljes tartományneve (FQDN) mögé vannak rejtve.
A helyek közötti VPN-átjáró esetében az átjáró két példánya lesz üzembe helyezve egy virtuális központban. Az átjárópéldányok mindegyike saját nyilvános és privát IP-címekkel van üzembe helyezve. A két példány két független alagútvégpontot biztosít a helyek közötti VPN-kapcsolatok létrehozásához az ágakból. A magas rendelkezésre állás maximalizálása érdekében tekintse meg az Azure-útvonal kiválasztását több internetszolgáltatói hivatkozás között.
A hálózati architektúra magas rendelkezésre állásának maximalizálása kulcsfontosságú első lépés az üzletmenet-folytonosság és vészhelyreállítás (BCDR) szempontjából. A cikk további részében, amint azt korábban is említettük, menjünk túl a magas rendelkezésre álláson, és beszéljük meg, hogyan építheti ki a Virtual WAN kapcsolati hálózatát a BCDR-hez.
Vészhelyreállítás tervezésének szükségessége
A katasztrófa bármikor, bárhol bekövetkezhet. Katasztrófa történhet felhőszolgáltatói régiókban vagy hálózatokban, szolgáltatói hálózaton vagy helyszíni hálózaton belül. A felhő vagy a hálózati szolgáltatás regionális hatása bizonyos tényezők, például a természeti katasztrófa, az emberi hibák, a háború, a terrorizmus, a helytelen konfiguráció miatt nehezen zárható ki. Az üzletileg kritikus fontosságú alkalmazások folytonosságához tehát vészhelyreállítási kialakításra van szükség. Az átfogó vészhelyreállítási tervezéshez azonosítania kell azokat a függőségeket, amelyek esetleg meghiúsulhatnak a végpontok közötti kommunikációs útvonalon, és létre kell hoznia az egyes függőségek nem egymást átfedő redundanciáit.
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:
A redundáns kapcsolat 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 (például NAT, tűzfal) rendelkezik az útvonalon, az aszimmetrikus útválasztás blokkolhatja a forgalmat. A privát kapcsolatokon keresztül általában nem lesznek állapotalapú entitások, például NAT vagy tűzfalak. Ezért a magánkapcsolaton keresztüli aszimmetrikus útválasztás nem feltétlenül blokkolja a forgalom áramlását.
Ha azonban a georedundáns párhuzamos útvonalak közötti forgalmat terheléselosztja, a párhuzamos kapcsolatok fizikai útvonalának különbsége miatt inkonzisztens hálózati teljesítményt tapasztalhat. Ezért a vészhelyreállítási terv részeként figyelembe kell vennünk a hálózati forgalom teljesítményét az állandó állapot (nem meghibásodási állapot) és a meghibásodási állapot során is.
Hálózati redundancia elérése
A legtöbb SD-WAN-szolgáltatás (felügyelt megoldás vagy egyéb módon) több átviteli típuson (például internetes szélessávú, MPLS, LTE) keresztül biztosít hálózati kapcsolatot. Az átviteli hálózati hibák elleni védelem érdekében válasszon egynél több átviteli hálózaton keresztüli kapcsolatot. Otthoni felhasználói forgatókönyv esetén érdemes lehet a mobilhálózatot biztonsági mentésként használni a szélessávú hálózati kapcsolatokhoz.
Ha a hálózati kapcsolat nem lehetséges különböző átviteli típuson keresztül, akkor válassza a hálózati kapcsolatot egynél több szolgáltatón keresztül. Ha egynél több szolgáltatón keresztül szerez kapcsolatot, győződjön meg arról, hogy a szolgáltatók nem fedik egymást át a független hozzáférési hálózatokat.
Távoli felhasználói kapcsolati szempontok
A távoli felhasználói kapcsolat pont–hely VPN használatával jön létre egy végfelhasználói eszköz és egy hálózat között. Hálózati hiba esetén a végeszköz leesik, és megkísérli újra létrehozni a VPN-alagutat. Ezért pont–hely VPN esetén a vészhelyreállítási tervnek a meghibásodást követő helyreállítási idő minimalizálására kell törekednie. Az alábbi hálózati redundancia segít minimalizálni a helyreállítási időt. Attól függően, hogy mennyire kritikusak a kapcsolatok, ezek közül választhat néhányat vagy az összeset.
- Hálózati redundancia elérése (fentebb tárgyalt).
- Redundáns virtuális központ kezelése pont–hely VPN leálláshoz. Ha több virtuális központtal rendelkezik pont–hely átjárókkal, a VWAN az összes pont–hely végpontot felsoroló globális profilt biztosít. A globális profillal a végfelhasználók a legjobb hálózati teljesítményt kínáló legközelebbi elérhető virtuális központhoz csatlakozhatnak. Ha az összes Azure-üzemelő példány egyetlen régióban található, és a csatlakozó végeszközök közel vannak a régióhoz, redundáns virtuális központokkal rendelkezhet a régión belül. Ha az üzembe helyezés és a végpontok több régióban is el vannak osztva, a virtuális központot pont–hely átjáróval helyezheti üzembe az egyes kiválasztott régiókban. A Virtual WAN beépített traffic managerrel rendelkezik, amely automatikusan kiválasztja a legjobb központot a távoli felhasználói kapcsolatokhoz.
Az alábbi ábrán a redundáns virtuális központ és a hozzájuk tartozó pont–hely átjáró kezelésének koncepciója látható egy régión belül.
A fenti ábrán az egyszínű zöld vonalak az elsődleges pont–hely VPN-kapcsolatokat, a pontozott sárga vonalak pedig az készenléti biztonsági mentési kapcsolatokat mutatják. A VWAN pont–hely globális profil a hálózati teljesítmény alapján választja ki az elsődleges és biztonsági mentési kapcsolatokat. A globális profillal kapcsolatos további információkért lásd : A felhasználói VPN-ügyfelek globális profiljának letöltése.
Helyek közötti VPN-szempontok
Tekintsük át a következő ábrán látható példa helyek közötti VPN-kapcsolatot a vitafórumhoz. Helyek közötti VPN-kapcsolat magas rendelkezésre állású aktív-aktív alagutakkal való létesítéséhez tekintse meg a következő oktatóanyagot: Helyek közötti kapcsolat létrehozása az Azure Virtual WAN használatával.
Feljegyzés
A szakaszban tárgyalt fogalmak egyszerű megértéséhez nem ismételjük meg a helyek közötti VPN-átjáró magas rendelkezésre állású funkciójának megvitatását, amely lehetővé teszi két alagút létrehozását két különböző végponthoz minden konfigurált VPN-kapcsolathoz. A szakaszban javasolt architektúrák bármelyikének üzembe helyezésekor azonban ne felejtsen el két alagutat konfigurálni minden egyes létesített hivatkozáshoz.
Többhivatkozásos topológia
Annak érdekében, hogy védelmet nyújtsunk a VPN-ügyfélberendezés (CPE) meghibásodásai ellen egy fiókhelyen, konfigurálhatja a VPN-átjáróhoz való párhuzamos VPN-kapcsolatokat a fiókhely párhuzamos CPE-eszközeiről. A fiókirodához az utolsó mérföldes szolgáltató hálózati hibáival szembeni védelem érdekében különböző VPN-kapcsolatokat konfigurálhat különböző szolgáltatói hálózaton keresztül. Az alábbi ábra több VPN-kapcsolatot mutat be, amelyek egy ágwebhely két különböző processzorából származnak, és ugyanazon a VPN-átjárón végződnek.
Egy virtuális központ VPN-átjárójából legfeljebb négy, a fiókwebhelyre mutató hivatkozást konfigurálhat. Egy ágwebhelyre mutató hivatkozás konfigurálása során azonosíthatja a szolgáltatót és a hivatkozáshoz társított átviteli sebességet. Ha egy ághely és egy virtuális központ közötti párhuzamos kapcsolatokat konfigurál, a VPN-átjáró alapértelmezés szerint betölti a párhuzamos kapcsolatok közötti forgalmat. A forgalom terheléselosztása a folyamatonkénti egyenlő költségű többútvonalos (ECMP) szerint történik.
Többközpontos többkapcsolatos topológia
A többhivatkozásos topológia védelmet nyújt a CPE-eszközök meghibásodása és a szolgáltató hálózati meghibásodása ellen a helyszíni ág helyén. Emellett a virtuális központok VPN-átjáróinak állásideje elleni védelemhez a többközpontos többkapcsolatos topológia is segíthet. Az alábbi diagram a topológiát mutatja be, amelyben több virtuális központ van konfigurálva egy régión belüli Virtual WAN-példány alatt:
A fenti topológiában, mivel az Azure-régión belüli késés a központok közötti kapcsolatnál jelentéktelen, használhatja a helyszíni és a két virtuális központ közötti, aktív-aktív állapotban lévő összes helyek közötti VPN-kapcsolatot a küllő virtuális hálózatok hubokon való terjesztésével. A topológiában alapértelmezés szerint a helyszíni és a küllős virtuális hálózat közötti forgalom közvetlenül azon a virtuális központon halad át, amelyhez a küllős virtuális hálózat csatlakozik az állandó állapot során, és egy másik virtuális központot csak meghibásodási állapotban használ biztonsági mentésként. A forgalom állandó állapotban haladna át a közvetlenül csatlakoztatott hubon, mivel a közvetlenül csatlakoztatott központ által meghirdetett BGP-útvonalak rövidebb AS-elérési úttal rendelkeznének a biztonsági mentési központhoz képest.
A többközpontos többkapcsolatos topológia a legtöbb hibaforgatókönyv esetében védelmet és üzletmenet-folytonosságot biztosít. Ha azonban egy katasztrofális hiba a teljes Azure-régiót leálltatja, akkor a hiba elviseléséhez "többrégiós többkapcsolatos topológiára" van szükség.
Többrégiós többhivatkozásos topológia
A többrégiós többkapcsolatos topológia egy teljes régió katasztrofális meghibásodása ellen is védelmet nyújt a korábban tárgyalt többhelyes többkapcsolatos topológia által nyújtott védelem mellett. Az alábbi ábrán a többrégiós többhivatkozásos topológia látható. A különböző régióban lévő virtuális központok ugyanazon Virtual WAN-példány alatt konfigurálhatók.
Forgalommérnöki szempontból figyelembe kell vennie egy lényeges különbséget a redundáns központok régión belüli és a biztonsági mentési központ egy másik régióban való használata között. A különbség az elsődleges és másodlagos régiók közötti fizikai távolságból eredő késés. Ezért érdemes lehet az állandó állapotú szolgáltatás erőforrásait a fiókhoz/végfelhasználókhoz legközelebbi régióban üzembe helyezni, és a távoli régiót kizárólag biztonsági mentésre használni.
Ha a helyszíni ág helyei két vagy több Azure-régió köré vannak elosztva, a többrégiós többkapcsolatos topológia hatékonyabb lenne a terhelés terjesztésében és a jobb hálózati élmény elérésében az állandó állapot során. Az alábbi ábrán a többrégiós többhivatkozásos topológia látható, különböző régiókban lévő ágakkal. Ilyen esetben a topológia emellett hatékony üzletmenet-folytonossági vészhelyreállítást (BCDR) is biztosítana.
Az ExpressRoute szempontjai
A privát ExpressRoute-társviszony-létesítés vészhelyreállítási szempontjait az ExpressRoute privát társviszony-létesítéssel történő vészhelyreállítás tervezése során tárgyaljuk. Ahogy a cikkben említettük, az ebben a cikkben ismertetett fogalmak a virtuális központban létrehozott ExpressRoute-átjárókra is érvényesek. A régión belüli redundáns virtuális központ használata, ahogyan az az alábbi ábrán is látható, az egyetlen topológiafejlesztés, amelyet kis és közepes helyszíni hálózati szempontok esetén ajánlott használni.
A fenti ábrán az ExpressRoute 2 leáll egy külön ExpressRoute-átjárón a régión belüli második virtuális központban.
Következő lépések
Ebben a cikkben a Virtual WAN vészhelyreállítási tervezéséről volt szó. 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 pont–hely kapcsolatot szeretne létrehozni a Virtual WAN-hoz, tekintse meg a következő oktatóanyagot: Felhasználói VPN-kapcsolat létrehozása az Azure Virtual WAN használatával. Helyek közötti kapcsolat virtuális WAN-kapcsolat létrehozásához lásd : Oktatóanyag: Helyek közötti kapcsolat létrehozása az Azure Virtual WAN használatával. Ha ExpressRoute-kapcsolatcsoportot szeretne társítani a Virtual WAN-hoz, tekintse meg az Oktatóanyagot: ExpressRoute-társítás létrehozása az Azure Virtual WAN használatával.