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.

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
• 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.