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 egy 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, egy másodlagos helyre kell feladatátvételt végeznie az alkalmazások eléréséhez. Amint az elsődleges hely újra fut, vissza is adhatja a feladatát. További információ: A Site Recovery ismertetése.
A virtuális gépek két Azure Stack Hub-bélyegen történő replikálásának engedélyezéséhez két környezetet kell konfigurálnia:
-
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őkorlátok (RTO) és helyreállítási pont célkitűzései (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 el?
- 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, hogy az egyes virtuális gépek hogyan vannak más virtuális gépekhez kötve.
- A több virtuális gépet igénylő megoldások esetében 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 a BCDR-terv létrehozásakor széles körű következményekkel jár.
Az alábbi szakaszok az Azure Site Recovery szempontjából figyelembe veendő 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 teljes.
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 feladat-visszavétel és az újravédelem egy belső hibaüzenettel meghiúsulhat. 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.
Célokkal kapcsolatos szempontok
A célkörnyezetben két szempontot kell figyelembe venni a kapacitástervezéshez:
Az Azure Site Recovery szolgáltatáskövetelményei: 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 nem kapacitás szempontjából korlátozott, figyelembe kell venni a teljes környezet tervezésének tervezésekor.
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 erőforrás-szolgáltatót (RP).
Megjegyzés
A Microsoft.SiteRecovery-1.2301.2216.2287 használatával az Azure Stack Hubon futó Azure Site Recovery nem igényel event Hubs függőséget.
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 esetében, ezek az erőforrások memóriát, tárterületet használnak, és bizonyos vCPU-k vannak lefoglalva:
| Szolgáltatás | virtuális mag | Memory (Memória) | Lemezméret |
|---|---|---|---|
| Azure Site Recovery | 12 | 42 GB | 1,4 TB |
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 munkaterhelések
A BCDR-csomag létrehozásakor vegye figyelembe a védett számítási feladatok összes aspektusát. A következő lista nem teljes, és 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.
Hálózati sávszélességre való tekintettel:
- A változásreplikációhoz szükséges hálózati sávszélesség.
- Az Azure Site Recovery által a forráskörnyezetből lekérhető átviteli sebesség a célkörnyezetben.
- A kötegelendő virtuális gépek száma egyszerre. Ez a szám a kezdeti replikáció adott idő alatt történő befejezéséhez 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.
- Hány helyreállítási pont van tárolva, és hogyan növekszik az adatok az egyes védett virtuális gépek esetében ezekben az időszakokban.
- 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ő foglalással rendelkezzenek.
- A replikáció gyorsítótár-tárfiókja.
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. A virtuálisgép-erőforrások elindításához elegendő kvótakiosztásnak kell lennie.
- 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 virtuális géphez kapcsolódó 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 a feladatátvétel tesztelése során válnak relevánssá.
Az Azure Stack Hubon futó Azure Site Recovery hatóköréhez íme egy kiindulópont a számításokhoz, különösen a használt gyorsítótár-tárfiók esetében:
Feladatátvétel esetén a normál műveletek során szorozza meg a replikált lemezek számát az átlagos RPO-val. Előfordulhat például, hogy rendelkezik (2 MB * 250s). A gyorsítótár tárfiókja lemezenként általában néhány KB–500 MB.
Ha feladatátvétel történik, a legrosszabb esetet figyelembe véve szorozza meg a replikált lemezek számát az átlagos RPO-val egy teljes napon keresztül.
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 úgy dönt, hogy időtúllépést végez.
Feladat-visszavétel az új virtuális gépre. Számítsa ki az egyes kötegek lemezméretének összegét.
- A cél virtuális gép alkalmazásához a teljes lemezt át kell másolni a 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örnyezetekben futtatott tesztekre. Ezzel az elemzéssel alapkonfigurációt kaphat saját alkalmazásához, de mindegyik 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 | Torlódás |
|---|---|---|---|
| 68 | 136 MB/s | 68 | storage |
| 60 | 120 MB/s | 2048 | storage |
| 28 | 28 MB/s | 3584 | Azure Site Recovery CPU és memória |
| 16 | 32 MB/s | 4096 |
Megjegyzés
A 8Kb az Azure Site Recovery által támogatott legkisebb blokkméret. 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 konzisztens tárolási változások 8 Kb-os blokkokban, 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 feladatokban fordul elő, 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 a következő 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 olyan virtuális gép, amely véletlenszerű időközönként, legalább óránként kétszer generál véletlenszerű blokkokat, összesen 5 Gb adatot generál öt fájlban.
A replikáció mind a 120 virtuális gépen sikerült, alacsony és közepes terheléssel az Azure Site Recovery-szolgáltatásokra.
Megjegyzés
Ezek a számok csak alapkonfigurációként használhatók. Nem feltétlenül skáláznak lineárisan. Az azonos számú virtuális gép egy másik kötegének hozzáadása kisebb hatással lehet a kezdetinél. Az eredmények nagymértékben függnek a használt számítási feladatok típusától.
Hogyan tervezze meg é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) kapcsolatos követelményekkel 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, amelyek megfelelnek 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 ezeket a tényezőket a tervezés során:
Alkalmazás- és adat rendelkezésre állási követelmények:
- RTO- és RPO-követelmények 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 üzemelő példányok támogatása feladatátvételhez, és az összetevők közelsége a teljesítményhez. Előfordulhat, hogy az alkalmazásműveleteket csökkentett funkcionalitással vagy csökkentett teljesítménnyel tapasztalja kimaradás esetén.
Megjegyzés
Előfordulhat, hogy az alkalmazás natív módon futtatható, vagy rendelkezik bizonyos összetevőkkel, amelyek több Azure Stack Hub-környezetben is futtathatók. Ebben az esetben az Azure Site Recovery használatával csak azokat a virtuális gépeket replikálhatja, amelyek nem rendelkeznek ezzel a funkcióval. Ilyen például egy előtér- vagy háttérmegoldás, amelyben üzembe helyezheti az előtérrendszereket az Azure Stack Hub-környezetekben.
Kerülje az egymást átfedő 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 folyamatot igényelnek, 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 a forrást és a célt 1:1-re használja, valamivel több tárterületet foglaljon le a célkörnyezetben. Ennek oka a lemez könyvjelzőinek előzményei. Ez a foglalás nem kétszeres növekedés, 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 több tárhellyel rendelkező replikációs szabályzatok biztosítják, hogy a feladatátvételi folyamatok ne vezessenek aggodalomra.
- 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 számítási feladatok leállnak; például melyik forrást kell rangsorba venni.
- 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 fejlesztési/tesztelési virtuális gépeket a célkörnyezetben, és ha probléma merül fel a forráskörnyezetben, 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 elindításához.
Tesztelje a BCDR-t, és ellenőrizze rendszeresen. Ezt elvégezheti feladatátvételi tesztfolyamatok használatával, vagy a teljes számítási feladatok áthelyezésével a folyamatok teljes körű ellenőrzéséhez.