Vészhelyreállítás tervezése
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 a különböző ágak, a jelenléti pontok (PoP), a magánfelhasználók, az irodák, az 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. A különböző helyek virtuális központhoz való csatlakoztatásához használhatja az SD-WAN-t, a helyek közötti VPN-t, a pont–hely VPN-t és az ExpressRoute-ot. Ha több virtuális központtal rendelkezik, az összes központ teljes hálóban csatlakozik egy standard Virtual WAN üzemelő példányban.
Ebből a cikkből megtudhatja, hogyan építhet ki különböző típusú, szolgáltatásként nyújtott hálózati kapcsolati lehetőségeket, amelyeket Virtual WAN támogat a vészhelyreállításhoz.
A Virtual WAN hálózati szolgáltatáskénti kapcsolati lehetőségei
Virtual WAN a következő háttérkapcsolati lehetőségeket 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 Virtual WAN külön átjárópéldány-készletet helyez üzembe egy virtuális központban.
A Virtual WAN eredendően szolgáltatói szintű magas rendelkezésre állású hálózati összesítési megoldást kínál. A magas rendelkezésre állás érdekében Virtual WAN több példányt is példányosít, ha mindegyik ilyen típusú átjáró üzembe van helyezve egy Virtual WAN hubon. További információ az ExpressRoute magas rendelkezésre állásáról: Magas rendelkezésre állás tervezése az ExpressRoute-tal.
A pont–hely VPN-átjáró esetében az üzembe helyezett példányok minimális száma kettő. A pont–hely TÍPUSÚ VPN-átjáróval kiválaszthatja a pont–hely átjárók összesített átviteli kapacitását, és több példány automatikusan ki lesz építve. Az összesített kapacitást a virtuális központhoz csatlakoztatni 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 rejtve vannak az átjáró teljes tartományneve (FQDN) mögött.
A helyek közötti VPN-átjáró esetében az átjáró két példánya egy virtuális központban van üzembe helyezve. Az átjárópéldányok mindegyike saját nyilvános és privát IP-címekkel van üzembe helyezve. Az alábbi képernyőfelvétel egy példa helyek közötti VPN Gateway-konfiguráció két példányához társított IP-címeket mutatja be. Más szóval 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 lásd: Azure-útvonal kiválasztása több ISP-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 a vészhelyreállítás (BCDR) szempontjából. A cikk további részében, ahogy korábban említettük, haladjunk túl a magas rendelkezésre álláson, és nézzük meg, hogyan építheti ki 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 lecsaphat. 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 hálózati szolgáltatások regionális hatása bizonyos tényezők, például a természeti csapások, 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 folyamatossága érdekében vészhelyreállítási tervet kell kialakítania. 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 minden függőséghez létre kell hoznia nem átfedésmentes redundanciát.
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 kapcsolatok használatának kihívásai
Ha ugyanazt a hálózatcsoportot több kapcsolattal összekapcsolja, párhuzamos útvonalakat vezet be a hálózatok között. A párhuzamos útvonalak, ha nem megfelelően van megadva, 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 forgalom áramlását. 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 forgalom georedundáns párhuzamos útvonalak közötti terheléselosztását használja, inkonzisztens hálózati teljesítményt tapasztalhat a párhuzamos kapcsolatok fizikai útvonalának különbsége miatt. Ezért figyelembe kell vennünk a hálózati forgalom teljesítményét mind az állandó (nem meghibásodási) állapot, mind pedig a vészhelyreállítási terv részeként.
Hálózati redundancia elérése
A legtöbb SD-WAN-szolgáltatás (felügyelt megoldás vagy más módon) több átviteli típuson keresztül biztosítja a hálózati kapcsolatot (például internetes szélessávú kapcsolat, MPLS, LTE). Az átviteli hálózati hibák elleni védelem érdekében válassza a 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 különböző átviteli típuson keresztüli hálózati kapcsolat nem lehetséges, válassza a hálózati kapcsolatot egynél több szolgáltatón keresztül. Ha több szolgáltatón keresztül létesít kapcsolatot, győződjön meg arról, hogy a szolgáltatók nem fedik egymást átfedő független hozzáférési hálózatokat.
Távoli felhasználói kapcsolattal kapcsolatos szempontok
A távoli felhasználói kapcsolat pont–hely VPN használatával jön létre egy végpont és egy hálózat között. Hálózati hiba után a végeszköz leáll, és megpróbálja ú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, választhat ezek közül a lehetőségek közül.
- Hozzáférés hálózati redundanciához (fentebb tárgyalt).
- Redundáns virtuális központ kezelése pont–hely VPN leállításához. Ha több, pont–hely átjáróval rendelkező virtuális központtal rendelkezik, 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 azure-beli üzemelő példányok egyetlen régióban vannak, és a csatlakozó végeszközök a régióhoz közel vannak, 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 vannak elosztva, üzembe helyezheti a virtuális központot pont–hely átjáróval az egyes kiválasztott régiókban. Virtual WAN rendelkezik egy beépített traffic managerrel, 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 a folytonos zöld vonalak az elsődleges pont–hely VPN-kapcsolatokat, a pontozott sárga vonalak pedig a készenléti biztonsági mentési kapcsolatokat mutatják. A VWAN pont–hely globális profilja a hálózati teljesítmény alapján választja ki az elsődleges és a biztonsági mentési kapcsolatokat. A globális profillal kapcsolatos további információkért lásd: Globális profil letöltése felhasználói VPN-ügyfelek számára .
Helyek közötti VPN-szempontok
Tekintsük át a következő ábrán látható, helyek közötti VPN-kapcsolatot bemutató példát 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 lásd: Oktatóanyag: Helyek közötti kapcsolat létrehozása az Azure Virtual WAN használatával.
Megjegyzés
A szakaszban ismertetett fogalmak egyszerű megértése érdekében 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 alagutat 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 mindegyik kapcsolathoz.
Többkapcsolatos topológia
A VPN Ügyféleszközök (CPE) meghibásodásai elleni védelem érdekében konfigurálhat párhuzamos VPN-kapcsolatokat egy VPN-átjáróhoz a fiókhelyen található párhuzamos CPE-eszközökről. A fiókiroda utolsó mérföldes szolgáltatójának 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 ábrán több VPN-kapcsolat látható, amelyek ugyanazon a VPN-átjárón végződő ághely két különböző PROCESSZORából származnak.
Egy virtuális központ VPN-átjárójáról legfeljebb négy, ághelyre mutató hivatkozást konfigurálhat. A fiókwebhelyre mutató hivatkozás konfigurálása során azonosíthatja a szolgáltatót és a hivatkozáshoz társított átviteli sebességet. Amikor párhuzamos kapcsolatokat konfigurál egy ághely és egy virtuális központ között, a VPN-átjáró alapértelmezés szerint terheléselosztást alkalmaz a párhuzamos kapcsolatok között. A forgalom terheléselosztása Equal-Cost többútvonalos (ECMP) folyamatonkénti alapján történik.
Több hubos többkapcsolatos topológia
A többkapcsolatos topológia védelmet nyújt a CPE-eszközhibák és a szolgáltatói hálózati hibák ellen a helyszíni ág helyén. Emellett a virtuális központok VPN-átjáróinak állásideje elleni védelem érdekében a több hubos többkapcsolatos topológia is segíthet. Az alábbi diagram azt 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ányban:
A fenti topológiában, mivel a központok közötti kapcsolat Azure-régión belüli késése jelentéktelen, használhatja a helyszíni és az aktív-aktív állapotban lévő két virtuális központ közötti összes helyek közötti VPN-kapcsolatot a küllő virtuális hálózatok központok közötti elosztásával. 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 használ biztonsági mentésként csak meghibásodási állapot esetén. A forgalom állandó állapotban haladna át a közvetlenül csatlakoztatott hubon, mert a közvetlenül csatlakoztatott központ által meghirdetett BGP-útvonalak rövidebb AS-útvonalon haladnának 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, a "többrégiós többkapcsolatos topológiára" van szükség a hiba kivédéséhez.
Többrégiós többkapcsolatos topológia
A többrégiós többkapcsolatos topológia a korábban tárgyalt többközpontos többkapcsolatos topológia által nyújtott védelem mellett egy teljes régió katasztrofális meghibásodása ellen is védelmet nyújt. Az alábbi ábrán a többrégiós többkapcsolatos topológia látható. A különböző régióban lévő virtuális központok ugyanabban a Virtual WAN példányban 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ül vannak elosztva, a többrégiós többkapcsolatos topológia hatékonyabb lenne a terhelés szétosztásában és a jobb hálózati élmény elérésében az állandó állapotban. Az alábbi ábrán a többrégiós többkapcsolatos 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 a Privát ExpressRoute-társviszony-létesítésű vészhelyreállítás tervezése című témakörben tárgyaljuk. Ahogy a cikkben említettük, a cikkben ismertetett fogalmak ugyanúgy vonatkoznak a virtuális központban létrehozott ExpressRoute-átjárókra is. A régión belüli redundáns virtuális központ használata, ahogy az az alábbi ábrán is látható, az egyetlen topológiafejlesztés, amelyet a kis és közepes helyszíni hálózati szempontokhoz ajánlott használni.
A fenti ábrán az ExpressRoute 2 le van állítva egy külön ExpressRoute-átjárón a régió egy második virtuális központjában.
Következő lépések
Ebben a cikkben a Virtual WAN vészhelyreállítás 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 Virtual WAN, tekintse meg az oktatóanyagot: Felhasználói VPN-kapcsolat létrehozása az Azure Virtual WAN használatával. Ha helyek közötti kapcsolatot szeretne létrehozni Virtual WAN lásd: Oktatóanyag: Helyek közötti kapcsolat létrehozása az Azure Virtual WAN használatával. ExpressRoute-kapcsolatcsoport Virtual WAN való társításához lásd: Oktatóanyag: ExpressRoute-társítás létrehozása az Azure Virtual WAN használatával.