IP-cím megőrzése a feladatátvétel során
Az Azure Site Recovery lehetővé teszi az Azure-beli virtuális gépek vészhelyreállítását úgy, hogy replikálja a virtuális gépeket egy másik Azure-régióba, meghiúsul a feladatátvétel, ha leállás történik, és ha a dolgok visszaállnak a normál állapotra, az elsődleges régióba kell visszaállnia.
A feladatátvétel során előfordulhat, hogy az IP-címzést a forrásrégióval megegyező célrégióban szeretné megőrizni:
- Alapértelmezés szerint ha engedélyezi az Azure-beli virtuális gépek vészhelyreállítását, Site Recovery a forráserőforrás-beállítások alapján létrehozza a célerőforrásokat. Statikus IP-címekkel konfigurált Azure-beli virtuális gépek esetében Site Recovery megpróbálja kiépíteni ugyanazt az IP-címet a cél virtuális géphez, ha nincs használatban. A Site Recovery kezelésének teljes körű magyarázatáért tekintse át ezt a cikket.
- Egyszerű alkalmazások esetén az alapértelmezett konfiguráció elegendő. Összetettebb alkalmazások esetén előfordulhat, hogy további erőforrást kell kiépítenie, hogy a kapcsolat a feladatátvétel után a várt módon működjön.
Ez a cikk néhány példát mutat be az IP-címek összetettebb példaforgatókönyvekben való megőrzésére. A példák a következők:
- Feladatátvétel az Azure-ban futó összes erőforrással rendelkező vállalat számára
- Feladatátvétel hibrid üzembe helyezéssel rendelkező vállalat számára, valamint a helyszínen és az Azure-ban futó erőforrások
Erőforrások az Azure-ban: teljes feladatátvétel
Az A vállalat rendelkezik az Azure-ban futó összes alkalmazással.
Feladatátvétel előtt
Megjegyzés
A replikáció mostantól a világ bármely két Azure-régiója között elvégezhető. Az ügyfelek már nem korlátozódnak a replikáció engedélyezésére a kontinensen belül.
Íme a feladatátvétel előtti architektúra.
- Az A vállalat azonos hálózatokkal és alhálózatokkal rendelkezik a forrás- és cél Azure-régiókban.
- A helyreállítási időkorlát (RTO) csökkentése érdekében a vállalat replikacsomópontokat használ SQL Server Always On, tartományvezérlők stb. Ezek a replikacsomópontok egy másik virtuális hálózaton találhatók a célrégióban, hogy VPN-helyek közötti kapcsolatot létesíthessenek a forrás- és célrégiók között. Ez nem lehetséges, ha ugyanazt az IP-címteret használja a forrásban és a célban.
- A feladatátvétel előtt a hálózati architektúra a következő:
- Az elsődleges régió az Azure Kelet-Ázsia
- Kelet-Ázsiában van egy 10.1.0.0/16 címtérrel rendelkező virtuális hálózat (forrás virtuális hálózat).
- Kelet-Ázsiában a számítási feladatok három alhálózatra vannak felosztva a virtuális hálózatban:
- 1. alhálózat: 10.1.1.0/24
- 2. alhálózat: 10.1.2.0/24
- 3. alhálózat: 10.1.3.0/24
- A másodlagos (cél) régió az Azure Délkelet-Ázsia
- Délkelet-Ázsia a forrás virtuális hálózattal megegyező helyreállítási virtuális hálózattal (Recovery VNet) rendelkezik.
- Délkelet-Ázsia rendelkezik egy további virtuális hálózattal (Azure VNet), 10.2.0.0/16 címtérrel.
- Az Azure-beli virtuális hálózat egy 10.2.4.0/24 címtérrel rendelkező alhálózatot (4. alhálózat) tartalmaz.
- A SQL Server Always On, tartományvezérlő stb. replikacsomópontjai a 4. alhálózatban találhatók.
- A forrás virtuális hálózat és az Azure-beli virtuális hálózat VPN helyek közötti kapcsolattal van összekapcsolva.
- A helyreállítási virtuális hálózat nincs más virtuális hálózathoz csatlakoztatva.
- Az A vállalat hozzárendeli/ellenőrzi a replikált elemek cél IP-címeit. A cél IP-cím megegyezik az egyes virtuális gépek forrás IP-címével.
- Az elsődleges régió az Azure Kelet-Ázsia
Feladatátvétel után
Ha egy forrásrégió leáll, az A vállalat feladatátvételt végezhet a célrégióban lévő összes erőforráson.
- Ha a cél IP-címek már a feladatátvétel előtt is érvényben van, az A vállalat képes a feladatátvétel vezénylésére, és automatikusan kapcsolatokat létesíthet a helyreállítási virtuális hálózat és az Azure virtuális hálózat közötti feladatátvétel után. Ezt az alábbi diagram szemlélteti.
- Az alkalmazáskövetelményektől függően a célrégióban lévő két virtuális hálózat (helyreállítási virtuális hálózat és Azure-beli virtuális hálózat) közötti kapcsolatok létesíthetők a feladatátvétel előtt, alatt (köztes lépésként) vagy után.
A vállalat helyreállítási tervekkel határozhatja meg, hogy mikor lesznek kapcsolatok.
Virtuális hálózatok közötti társviszony-létesítés vagy helyek közötti VPN használatával tudnak csatlakozni a virtuális hálózatokhoz.
- A virtuális hálózatok közötti társviszony-létesítés nem használ VPN-átjárót, és különböző korlátozásokkal rendelkezik.
- A virtuális hálózatok közötti társviszony-létesítés díjszabása eltér a virtuális hálózatok közötti VPN Gateway díjszabástól. Feladatátvétel esetén általában ugyanazt a csatlakozási módszert javasoljuk, mint a forráshálózatok, beleértve a kapcsolattípust is, a kiszámíthatatlan hálózati incidensek minimalizálása érdekében.
Erőforrások az Azure-ban: elkülönített alkalmazás feladatátvétele
Előfordulhat, hogy az alkalmazás szintjén kell feladatátvételt végrehajtania. Például egy dedikált alhálózaton található adott alkalmazás- vagy alkalmazásszint feladatátvétele.
- Ebben a forgatókönyvben bár megtarthatja az IP-címzést, ez általában nem ajánlott, mivel növeli a csatlakozási inkonzisztenciák esélyét. Emellett elveszíti az alhálózati kapcsolatot az ugyanazon az Azure-beli virtuális hálózaton belüli többi alhálózattal is.
- Az alhálózati szintű alkalmazások feladatátvételének egy jobb módja, ha különböző cél IP-címeket használ a feladatátvételhez (ha a forrás virtuális hálózaton lévő többi alhálózattal kell kapcsolatot létesítenie), vagy elkülönítheti az egyes alkalmazásokat a saját dedikált virtuális hálózatában a forrásrégióban. Az utóbbi megközelítéssel kapcsolatot létesíthet a forrásrégióban lévő hálózatok között, és ugyanazt a viselkedést emulálhatja, amikor feladatátvételt kell végrehajtania a célrégióba.
Ebben a példában az A vállalat a forrásrégióban lévő alkalmazásokat dedikált virtuális hálózatokba helyezi, és kapcsolatot létesít ezek között a virtuális hálózatok között. Ezzel a kialakítással elkülönített alkalmazás-feladatátvételt hajthatnak végre, és megtarthatják a forrás privát IP-címeit a célhálózaton.
Feladatátvétel előtt
A feladatátvétel előtt az architektúra a következő:
Az alkalmazás virtuális gépek az elsődleges Azure Kelet-Ázsia régióban vannak üzemeltetve:
- Alkalmazás1 A virtuális gépek az 1. virtuális hálózat forrás virtuális hálózatában találhatók: 10.1.0.0/16.
- App2 A virtuális gépek a 2. virtuális hálózat forrás virtuális hálózatában találhatók: 10.2.0.0/16.
- Az 1. forráshálózat két alhálózattal rendelkezik.
- A 2. forráshálózat két alhálózattal rendelkezik.
A másodlagos (cél) régió az Azure Délkelet-Ázsia – Délkelet-Ázsia helyreállítási virtuális hálózatokkal (Recovery VNet 1 és Recovery VNet 2) rendelkezik, amelyek megegyeznek az 1. forrás virtuális hálózattal és a 2. forrás virtuális hálózattal. - A Recovery VNet 1 és a Recovery VNet 2 két alhálózattal rendelkezik, amelyek megfelelnek az 1. forrás virtuális hálózat és a 2. forrás virtuális hálózat alhálózatainak – Délkelet-Ázsia további virtuális hálózattal (Azure VNet) rendelkezik a 10.3.0.0/16 címtérrel. - Az Azure-beli virtuális hálózat egy 10.3.4.0/24 címtérrel rendelkező alhálózatot (4. alhálózat) tartalmaz. - A SQL Server Always On, tartományvezérlő stb. replikacsomópontjai a 4. alhálózatban találhatók.
Számos helyek közötti VPN-kapcsolat létezik:
- Forrás VNet 1 és Azure VNet
- Forrás VNet 2 és Azure VNet
- Az 1. forrás virtuális hálózat és a 2. forrás virtuális hálózat vpn-helyek közötti kapcsolattal csatlakozik
A Recovery VNet 1 és a Recovery VNet 2 nem csatlakozik más virtuális hálózatokhoz.
Az A vállalat vpn-átjárókat konfigurál a Recovery VNet 1 és a Recovery VNet 2 rendszeren az RTO csökkentése érdekében.
A Recovery VNet1 és a Recovery VNet2 nem csatlakozik más virtuális hálózathoz.
A helyreállítási időkorlát (RTO) csökkentése érdekében a VPN-átjárók a feladatátvétel előtt a Recovery VNet1 és a Recovery VNet2 hálózaton vannak konfigurálva.
Feladatátvétel után
Egy alkalmazást érintő leállás vagy probléma esetén (a példában a **Forrás VNet 2- ben) az A vállalat az alábbi módon állíthatja helyre az érintett alkalmazást:
- Válassza le a VPN-kapcsolatokat a Forrás VNet1 és a Forrás VNet2, valamint a Forrás VNet2 és az Azure-beli virtuális hálózat között.
- VPN-kapcsolatokat hozhat létre a Forrás VNet1 és a Recovery VNet2, valamint a Recovery VNet2 és az Azure VNet között.
- Virtuális gépek feladatátvétele a Forrás VNet2-bőlhelyreállítási VNet2-be.
- Ez a példa további alkalmazások és hálózati kapcsolatok hozzáadására bővíthető. A javaslat az, hogy a lehető legnagyobb mértékben kövesse a hasonló kapcsolati modellt, ha a feladatátvétel forrásról célra történik.
- A VPN-átjárók nyilvános IP-címeket és átjáró-ugrásokat használnak a kapcsolatok létrehozásához. Ha nem szeretne nyilvános IP-címeket használni, vagy el szeretné kerülni az extra ugrásokat, használhatja az Azure-beli virtuális hálózatok közötti társviszony-létesítést a támogatott Azure-régiók virtuális hálózatai között.
Hibrid erőforrások: teljes feladatátvétel
Ebben a forgatókönyvben a B vállalat hibrid vállalkozást futtat, az alkalmazás-infrastruktúra egy része az Azure-ban fut, a többi pedig a helyszínen fut.
Feladatátvétel előtt
Így néz ki a hálózati architektúra a feladatátvétel előtt.
- Az alkalmazás virtuális gépeket az Azure Kelet-Ázsiában üzemelteti.
- Kelet-Ázsiában van egy 10.1.0.0/16 címtérrel rendelkező virtuális hálózat (forrás virtuális hálózat).
- Kelet-Ázsiában a számítási feladatok három alhálózatra vannak felosztva a forrás virtuális hálózatban:
- 1. alhálózat: 10.1.1.0/24
- 2. alhálózat: 10.1.2.0/24
- 3. alhálózat: 10.1.3.0/24, azure-beli virtuális hálózat használata a 10.1.0.0/16 címtérrel. Ennek a virtuális hálózatnak a neve Forrás virtuális hálózat
- Kelet-Ázsiában a számítási feladatok három alhálózatra vannak felosztva a forrás virtuális hálózatban:
- A másodlagos (cél) régió az Azure Délkelet-Ázsia:
- Délkelet-Ázsia a forrás virtuális hálózattal megegyező helyreállítási virtuális hálózattal (Recovery VNet) rendelkezik.
- A kelet-ázsiai virtuális gépek egy helyszíni adatközponthoz csatlakoznak az Azure ExpressRoute vagy a helyek közötti VPN használatával.
- Az RTO csökkentése érdekében a B vállalat átjárókat helyez üzembe a délkelet-ázsiai Azure-beli helyreállítási virtuális hálózaton a feladatátvétel előtt.
- A B vállalat cél IP-címeket rendel hozzá/ellenőriz replikált virtuális gépekhez. A cél IP-cím megegyezik az egyes virtuális gépek forrás IP-címével.
Feladatátvétel után
Ha a forrás regionális leállása történik, a B vállalat feladatátvételt hajthat végre az összes erőforráson a célrégióba.
- A feladatátvétel előtt már meglévő cél IP-címek esetében a B vállalat képes a feladatátvétel vezénylésére, és automatikusan kapcsolatokat létesíthet a helyreállítási virtuális hálózat és az Azure virtuális hálózat közötti feladatátvétel után.
- Az alkalmazáskövetelményektől függően a célrégióban lévő két virtuális hálózat (helyreállítási virtuális hálózat és Azure-beli virtuális hálózat) közötti kapcsolatok létesíthetők a feladatátvétel előtt, alatt (köztes lépésként) vagy után. A vállalat helyreállítási tervekkel határozhatja meg, hogy mikor lesznek kapcsolatok.
- Az Azure East Asia és a helyszíni adatközpont közötti eredeti kapcsolatot le kell választani, mielőtt létrejön a kapcsolat az Azure Délkelet-Ázsia és a helyszíni adatközpont között.
- A helyszíni útválasztás újra van konfigurálva, hogy a célrégióra és a feladatátvételt követő átjárókra mutasson.
Hibrid erőforrások: elkülönített alkalmazás feladatátvétele
A B vállalat nem tud feladatátvételt végrehajtani az alhálózat szintjén elkülönített alkalmazásokon. Ennek az az oka, hogy a forrás- és helyreállítási virtuális hálózatok címtartománya megegyezik, és a helyszíni kapcsolat eredeti forrása aktív.
- Az alkalmazások rugalmassága érdekében a B vállalatnak minden alkalmazást saját dedikált Azure-beli virtuális hálózatba kell helyeznie.
- Ha minden alkalmazás külön virtuális hálózaton található, a B vállalat feladatátvételt végezhet az elkülönített alkalmazásokon, és átirányíthatja a forráskapcsolatokat a célrégióba.
Következő lépések
Tudnivalók a helyreállítási tervekről.