Kapacitástervezés az Azure Site Recovery használatával

Szervezetként elengedhetetlen egy üzletmenet-folytonossági és vészhelyreállítási (BCDR) stratégia bevezetése, amely biztonságossá teszi az adatokat, az alkalmazásokat és a számítási feladatokat online állapotban tartja a tervezett és nem tervezett kimaradások során.

A virtuális gépek számítási feladatainak elsődleges helyről másodlagos helyre történő replikálásával az Azure Site Recovery az Azure Stack Hubon olyan szolgáltatásokat biztosít, amelyek támogatják a szervezeti adatok, az alkalmazások rendelkezésre állása és a számítási feladatok biztonságát a kimaradások során. Ha például leállás történik az elsődleges helyen, feladatátvétellel egy másodlagos helyre vált át az alkalmazások elérésére. Amint az elsődleges hely újra működik, visszaállíthat rá. További információ: A Site Recovery ismertetése.

Ha engedélyezni szeretné a virtuális gépek replikálását két Azure Stack Hub-bélyegen, két környezetet konfigurálhat:

• Forráskörnyezet :
  • Az Azure Stack Hub-bélyeg, amelyen a bérlői virtuális gépek futnak.
• Célkörnyezet :
  • Ahol az Azure Site Recovery-erőforrás-szolgáltató fut.

Az üzletmenet-folytonossági és vészhelyreállítási terv sikerének alapvető összetevője a kapacitástervezés. A kapacitástervezés során figyelembe kell venni néhány tényezőt:

• Helyreállítási idő célkitűzései (RTO) és helyreállításipont-célkitűzések (RPO) a védeni kívánt adott számítási feladatokhoz.

• Számítási feladatok és az alkalmazás jellemzői:

  • Milyen gyakran változnak az adatok az adott virtuális gépen belül.
  • Mennyi adat jön létre vagy távolítódik?
  • Hogyan néz ki az alkalmazástervezés és még sok más?

• A virtuális gépek mérete, a lemezek száma, valamint az egyes virtuális gépek más virtuális gépekhez való kötődésének módját.

  • Több virtuális gépet igénylő megoldások esetén ismerje meg, hogy milyen sorrendben kell elindítani ezeket a virtuális gépeket.

• Hálózati sávszélesség a forrás- és célkörnyezetek között. Ez az összetevő hatással lehet az RPO-kra.

E pontok mindegyike fontos, és széles körű következményekkel jár a BCDR-terv létrehozásakor.

Az alábbi szakaszok az Azure Site Recovery szempontjából megfontolandó főbb szempontokat sorolják fel. Minden BCDR-csomag eltérő, és a védeni kívánt számítási feladatok jellemzőin alapul. Ezért ez a lista nem átfogó.

Forrásokkal kapcsolatos szempontok

A forráskörnyezetben az Azure Stack Hub futtatja az Azure Site Recovery virtuálisgép-berendezést. A virtuális gép egy Standard_DS4_v2 (8 virtuális processzor, 28 Gb memória, 32 adatlemez) virtuális gép, amely az Azure Stack Hub felhasználói előfizetésében fut.

A forráskörnyezetben vegye figyelembe a következő területeket:

• Kvóta:

  • Elegendő kvótával kell rendelkeznie az Azure Site Recovery virtuálisgép-berendezés létrehozásához. Az általános tervtől függően egy vagy többre van szüksége.

• Az Azure Site Recovery virtuálisgép-berendezés tárolója:

  • Maga az Azure Site Recovery virtuálisgép-berendezés rendelkezik a virtuális gép mérete által meghatározott adatkövetelményekkel.

  • A kapacitás tervezésekor győződjön meg arról, hogy a berendezés virtuális gépe rendelkezik elegendő tárhellyel a feladat-visszavételi és újravédelmi mechanizmusok használatához.

    Megjegyzés:

    Ha vannak tárolási korlátozások, a visszaállítás és az újravédés meghiúsulhat egy Belső hiba történt üzenettel. A felhasználóknak ellenőriznie kell a berendezés eseménynaplóit a tényleges Azure Resource Manager-hiba megerősítéséhez. További információ: Az Azure Site Recovery ismert problémái.

• Sávszélesség:

  • A kezdeti replikáció nagy sávszélesség-használatot eredményez.
  • A rendszer replikálja az egyes virtuális gépek módosításait a replikációs szabályzatoktól és az egyes alkalmazástípusoktól függően.

A célokkal kapcsolatos szempontok

A célkörnyezetben két szempontot kell figyelembe venni a kapacitástervezéshez:

• Az Azure Site Recovery szolgáltatásra vonatkozó követelmények: az Azure Site Recovery futtatásához felhasznált mennyiség, anélkül, hogy feltétlenül védené a számítási feladatokat.

• A védett számítási feladatokra vonatkozó követelmények.

A célkörnyezethez minden Site Recovery-berendezéshez létre kell hoznia egy Azure Site Recovery-tárolót, hogy megvédje a virtuális gépeket a forrástól (tárolónként egy berendezés). Bár ez a kapacitás szempontjából nem korlátozás, a teljes környezet tervezésekor figyelembe kell venni.

Azure Site Recovery RP-erőforrások

Az Azure Site Recovery Azure Stack Hubon való telepítéséhez telepítenie kell a Site Recovery Resource Providert (RP).

Megjegyzés:

A Microsoft.SiteRecovery-1.2301.2216.2287-ben az Azure Stack Hubon futó Azure Site Recovery nem igényel eseményközpontokat függőségként.

Ez a szolgáltatás az Azure Stack Hub rendszergazdai előfizetésében jön létre, és maga az Azure Stack Hub felügyeli, ezért nincs szükség konfigurációra. Azonban, mint minden szolgáltatás, ezek az erőforrások memóriát, tárterületet használnak fel, és bizonyos vCPU-k vannak lefoglalva:

Szolgáltatás	virtuális processzormag	Memória	Lemezméret
Azure Site Recovery - az Azure vészhelyreállítási szolgáltatása	18	64 GB	384 GB

Megjegyzés:

Ezek az erőforrások az Azure Stack Hub felügyeleti oldalán található Azure Stack Hub-szolgáltatások. A telepítés után a platform kezeli ezeket az erőforrásokat.

Védett számítási terhelések

A BCDR-terv létrehozásakor vegye figyelembe a védett számítási feladatok minden aspektusát. A következő lista nem teljes, ezért kiindulási pontként kell kezelni:

• Virtuális gép mérete, lemezek száma, lemezméret, IOPS, adatváltozás és új létrehozott adatok.

• A hálózati sávszélesség szempontjai:

  • A különbözeti replikációhoz szükséges hálózati sávszélesség.
  • Az Azure Site Recovery által a forráskörnyezetből a célkörnyezetben elérhető átviteli teljesítmény.
  • Az egyszerre csoportosítandó virtuális gépek száma. Ez a szám a kezdeti replikáció adott időtartamon belüli végrehajtásához szükséges becsült sávszélességen alapul.
  • Az adott sávszélességhez elérhető RPO.
  • A kívánt RPO-ra gyakorolt hatás, ha alacsonyabb sávszélesség van kiépítve.

• Tárolási szempontok:

  • Mennyi adat szükséges a kezdeti replikációhoz.
  • Az egyes védett virtuális gépekhez tartozó helyreállítási pontok száma és az adatok növekedése ezekben az intervallumokban.
  • Hány kvótát kell hozzárendelni a cél Azure Stack Hub-felhasználói előfizetésekhez, hogy a felhasználók elegendő lefoglalással rendelkezzenek.
  • A replikáció számára kialakított gyorsítótár tároló fiók.

• Számítási szempontok:

  • Feladatátvétel esetén a virtuális gépek a cél Azure Stack Hub-felhasználói előfizetéseken indulnak el. Elegendő kvótakiosztásnak kell lennie ahhoz, hogy elindíthassa ezeket a virtuálisgép-erőforrásokat.
  • A virtuális gép védelme során, amikor a védett virtuális gép aktív a forráskörnyezetben, a célkörnyezetben nem használnak fel virtuális géppel kapcsolatos erőforrásokat, például vCPU-t, memóriát stb. Ezek az erőforrások csak a feladatátvételi folyamat, például tesztelési feladatátvétel során válnak relevánssá.

Az Azure Stack Hubon futó Azure Site Recovery hatóköréhez íme egy kezdőpont a számításokhoz, különösen a használt gyorsítótár-tárfiók esetében:

1. Ha feladatátvétel történik, a normál műveletek során szorozza meg a replikált lemezek számát az átlagos RPO-val. Például van egy eset, ahol 2 MB * 250 s az érték. A gyorsítótár tárfiókja lemezenként általában néhány KB–500 MB.

2. Ha feladatátvétel történik, a legrosszabb esetet figyelembe véve szorozza meg a replikált lemezek számát az átlagos napi RPO-val.

   Fontos

   Ha az Azure Site Recovery egyes részei nem működnek, de mások dolgoznak, legfeljebb egy napnyi difflog lehet a tárfiókban, mielőtt az Azure Site Recovery időtúllépést határoz meg.

3. Visszaállás az új virtuális gépre. Számítsa ki az egyes kötegek lemezméretének összegét.

   • A teljes lemezt át kell másolni a cél virtuális gép gyorsítótár-tárfiókjába, mivel a cél egy üres lemez.
   • A társított adatok a másolás után törlődnek, de valószínűleg az összes lemezméret összegével jelenik meg a maximális kihasználtság.

Hozza létre a BDCR-csomagot a védeni kívánt megoldás jellemzői alapján.

Az alábbi táblázat egy példa a környezeteinkben futtatott tesztekre. Ezzel az elemzéssel alapkonfigurációt kaphat saját alkalmazásához, de minden számítási feladat eltérő:

Konfiguráció

Blokkméret	Átviteli sebesség/lemez
2 MB	2 MB/s
64 KB	2 MB/s
8 KB	1 MB/s
8 KB	2 MB/s

Eredmény

Támogatott lemezek száma	Teljes átviteli sebesség	Összes OPS	Szűk keresztmetszet
68	136 MB/s	68	tárolás
60	120 MB/s	2048	tárolás
28	28 MB/s	3584	Azure Site Recovery CPU és memória
16	32 MB/s	4096

Megjegyzés:

A 8 Kb az Azure Site Recovery által támogatott adatok legkisebb blokkmérete. A 8 Kb-nál kisebb módosítások 8 Kb-ként lesznek kezelve.

A további teszteléshez konzisztens számítási feladattípust hoztunk létre; Például a 8 kb-os blokkokban a tárolók konzisztens változásai, amelyek lemezenként legfeljebb 1 MB/s méretűek. Ez a forgatókönyv valószínűleg nem valós számítási feladat, mivel a változások a nap különböző időszakaiban vagy különböző méretű csúcsokban fordulhatnak elő.

A véletlenszerű minták replikálásához az alábbi forgatókönyveket is teszteltük:

• 120 virtuális gép (80 Windows, 40 Linux) védett ugyanazzal az Azure Site Recovery virtuálisgép-berendezéssel.

  • Minden virtuális gép véletlenszerű időközönként, legalább óránként kétszer generál véletlenszerű blokkokat, amelyek összesen 5 Gb adatot generálnak öt fájlban.

  • A replikáció mind a 120 virtuális gépen sikeres volt, és az Azure Site Recovery-szolgáltatások terhelése alacsony és közepes volt.

    Megjegyzés:

    Ezek a számok csak alapkonfigurációként használhatók. Nem feltétlenül lineárisan skálázhatók. Az azonos számú virtuális gépből álló másik köteg hozzáadása kisebb hatással lehet a kezdetinél. Az eredmények nagymértékben függenek a használt számítási feladatok típusától.

Hogyan tervezze és tesztelje?

Az alkalmazások és a megoldás számítási feladatai bizonyos helyreállítási időkorláttal (RTO) és helyreállításipont-célkitűzéssel (RPO) rendelkeznek. A hatékony üzletmenet-folytonossági és vészhelyreállítási (BCDR) kialakítás mindkét platformszintű képességet kihasználja, amely megfelel ezeknek a követelményeknek, mivel a megoldásspecifikus mechanizmusokat használjuk. A BCDR-képességek tervezéséhez rögzítse a platform vészhelyreállítási (DR) követelményeit, és vegye figyelembe a tervezés során a következő tényezőket:

• Alkalmazás- és adat rendelkezésre állási követelmények:

  • Az RTO és az RPO követelményei az egyes számítási feladatokhoz.
  • Aktív-aktív és aktív-passzív rendelkezésre állási minták támogatása.

• Többrégiós elosztás támogatása átkapcsolás esetén, az összetevők teljesítmény-közeli elhelyezkedésével. Előfordulhat, hogy az alkalmazásműveleteket csökkentett funkcionalitással vagy csökkentett teljesítménnyel tapasztalja egy üzemkimaradás során.

  Megjegyzés:

  Előfordulhat, hogy az alkalmazás natív módon futtatható, vagy olyan összetevőkkel rendelkezik, amelyek több Azure Stack Hub-környezetben is futtathatók. Ebben az esetben az Azure Site Recovery használatával csak a virtuális gépeket replikálhatja azokkal az összetevőkkel, amelyek nem rendelkeznek ezzel a funkcióval; Például egy előtér- vagy háttérmegoldás, amelyben üzembe helyezheti az előtéreket az Azure Stack Hub-környezetekben.

• Kerülje az átfedésben lévő IP-címtartományok használatát az éles és a DR-hálózatokban.

  • Az egymást átfedő IP-címekkel rendelkező éles és DR hálózatok feladatátvételi folyamatra van szükség, amely bonyolíthatja és késleltetheti az alkalmazások feladatátvételét. Ha lehetséges, tervezze meg a BCDR hálózati architektúrát, amely egyidejű kapcsolatot biztosít az összes helyhez.

• A célkörnyezetek méretezése:

  • Ha 1:1-ben használja a forrást és a célt, foglaljon le valamivel több tárterületet a célkörnyezetben. Ennek oka, ahogyan a lemez könyvjelzőinek előzményei történnek. Ez a kiosztás nem duplázódik, mivel csak az adatok módosításait tartalmazza. Az adatok típusától és a várt változásoktól függően, valamint az 1,5-2x nagyobb tárterületet tartalmazó replikációs szabályzatok biztosítják, hogy a feladatátvételi folyamatok ne legyenek aggályosak.
  • Megfontolhatja, hogy a cél Azure Stack Hub-környezet legyen több Azure Stack Hub-forrás célhelye. Ebben az esetben csökkenti a teljes költséget, de meg kell terveznie, hogy mi történik, ha bizonyos munkaterhelések leállnak; például melyik forrást kell előnyben részesíteni.
  • Ha a célkörnyezetet más számítási feladatok futtatására használják, a BCDR-csomagnak tartalmaznia kell ezeknek a számítási feladatoknak a viselkedését. Futtathatja például a dev/test virtuális gépeket a célkörnyezetben, és ha probléma merül fel a forráskörnyezettel kapcsolatban, kikapcsolhatja a cél összes virtuális gépét, hogy elegendő erőforrás álljon rendelkezésre a védett virtuális gépek indításához.

Tesztelje a BCDR-t, és ellenőrizze rendszeresen. Ezt feladatátvételi tesztfolyamatok használatával vagy a teljes számítási feladatok áthelyezésével teheti meg a folyamatok teljes körű ellenőrzéséhez.

Következő lépések

Azure Site Recovery az Azure Stack Hubon