Azure Site Recovery avagy a költséghatékony BCDR megoldás

Az Azure Site Recovery (ASR), egy DRaaS1 szolgáltatás, amit felhős és hibrid architektúrákban használható. Az állandó replikáció által biztosítva van a másolatok szinkronizációja. Az ASR alkalmazás konzisztens pillanatkép funkciója biztosítja, hogy az adatok a feladatátvételt követően használható állapotban legyenek. A szolgáltatás lehetővé teszi az ügyfeleknek, hogy az Azure-t egy DR site-ként használják anélkül, hogy egy másodlagos infrastruktúrába invesztáljanak. 

DR platformként az ASR többféle megoldást támogat: 

• földi fizikai kiszolgálók replikációja Azure-ba 
• VMware vagy Hyper-V által hosztolt Windows vagy Linux VM-ek replikációja Azure-ba 
• AWS-en futó Windows VM-ek replikációja Azure-ba 
• Azure Stack-en futó Windows vagy Linux replikációja Azure-ba 

 

Az ASR előnyei

Költséghatékonyság: a replikált adatok tárolási költségein felül, az ASR a védett példányokért számol fel költséget. A szolgáltatás az első 31 napban ingyenes. A replikált adatok átlagosan 50%-os tömörítési aránnyal kerülnek tárolásra, ezzel is csökkentve a tárhely költségeket. 

Adat rugalmasság: a replikált adatok Azure storage-on tárolódnak, melyek lehetnek LRS (Locally-Redundant Storage) vagy GRS (Geo-Redundant Storage) típusú tárolók. LRS tárhely esetében az adatokról 3 másolat elérhető, amelyek adatközponti kiesések ellen védve vannak, aki nagyobb biztonságban szeretné tudni adatait, az választhatja adatai tárolását GRS tárolóban, ami regionális szolgáltatás kiesésektől véd. 

Heterogén workload-ok: az ASR támogatja a helyszíni kiszolgálókon, VMware vagy Hyper-V-ben futó VM-ek vagy harmadik féltől származó hoszting platformokon vagy felhőben tárolt Windows és Linux workload-ok védelmét. Továbbá Azure-ban futó VM-ek védelmét is támogatja regionális szolgáltatás kiesésektől. Az ASR konzolja egységes képet nyújt a különböző workload-ok replikációs állapotáról és lehetővé teszi a karbantartási feladatok végrehajtását. Pld.: helyreállítási tervek módosítása. 

RPO² * és RTO³ ** célok: az ASR akár 30 másodperces időközönként tud replikációs folyamatokat elvégezni, továbbá szervezetek igényeire is testreszabható. A visszaállítási tervbe integrált automatizált runbook-ok és Traffic manager szolgáltatásokkal az RTO könnyedén csökkenthető. A helyreállítási tervek nagymértékben testre szabhatok, ezáltal lehetővé teszik a gyors és egymás utáni feladatátvételt, valamint a többrétegű alkalmazások pld.: adatbázisok és webszolgáltatások helyreállítását. 

Adatreplikáció felhőbe ASR segítségével

Mint minden egyes DRaaS *** és migrációs projektnél, a vállalatnak első sorban szüksége van egy agilis tervre, ami a sikeres DRaaS stratégiát biztosítja. 

1.Tervezési fázis

Számos tényező alakítja a DRaaS stratégiát: RTO és RPO célok, Storage (IOPS és Storage Account), kapacitás tervezés, hálózat sávszélesség, hálózat újrakonfigurálás és a napi változás mértéke. Az Azure Site Recovery Deployment Planner segít elemezni a meglévő VMware és Hyper-V környezeteket, segítségével megtervezhető a cél Azure környezet kapacitása és mérete. További kritikus pont a hálózat tervezése. Az ügyfelek választhatnak, hogy a meglévő IP cím tartományukat vagy egy teljesen új IP cím tartományt kívánnak használni az Azure-ban, feladatátvételt követően. Következő lépésként meg kell vizsgálni a támogatási mátrixot, hogy érthetőek legyenek az ASR előfeltételei és limitációi, miközben a VM-ek és fizikai kiszolgálók replikálódnak az Azureba. 

2. Előkészítésés konfigurációs fázis 

A meglévő infrastruktúra által most már rendelkezésre áll egy terv, tehát megkezdhető a meglévő környezet replikációja. Az első lépés ennek a felkészítése. 

Az ASR többféle virtualizációs környezetet támogat pld.: VMware, Hyper-V, fizikai szerverek és Azure VM-ek. Használható más felhőszolgáltatók pld.: AWS-en futó VM-ek DR-jéhez vagy harmadik féltől származó hosztolt szolgáltatásokhoz, ezeknek a védelmére ugyan azt az folyamatot használva, mint a fizikai kiszolgálók esetében. Itt még fontos megjegyezni, hogy minden forrás környezet más és más igényekkel rendelkezik. Például VMware-en futó VM-nek szükséges további erőforrás, mint pld.: konfigurációs szerver, process szerver, és mobilitási szolgáltatások, amik segítenek kezelni és koordinálni a tömörített adatrészek elküldésését a Recovery Services-be. A következő lépés a célkörnyezet előkészítése az Azure-ban. Első lépésként létre kell hozni egy Recovery Services Vault-ot, ami menedzselni fogja a replikációt, valamint tárolja a replikáció beállításait. Ezután egy Storage és Network Account létrehozása a következő lépés, ahol a replikált VM-ek tárolódnak. (Storage Account esetében választani kell Standard vagy Premium account típus között, illetve LRS vagy GRS replikáció opciók közül amelyik közelebb áll az RPO elváráshoz). Végezetül megkezdődhet a replikáció engedélyezése és konfigurálása. Miután a forrás és cél környezet megfelelően elő lett készítve, replikációs tervet kell készíteni, ami igazodik az RTO és RPO célokhoz. Következőként lépés a replikálni kívánt VM-ek és replikációs szabály kiválasztása. Végezetül a kezdeti replikát kell engedélyezni, miután a kezdeti replika befejeződött az ASR a megváltozott adatokat, meghatározott időközönként adatrészenként replikálja (ami korábban meg lett határozva a replikációs szabályzatban). 

3. Feladat átvétel és feladat visszavétel

Most, hogy már rendelkezésre áll egy terv ideje kipróbálni a feladat átvételt. 3 különböző típusát különböztetjük meg a feladat átvételnek: teszt, tervezett és nem tervezett feladatátvétel. A teszt feladat átvételnek nincs hatása az éles környezetre, de egy tervezett vagy nem tervezett feladat átvétel magába foglalja az éles rendszer áthelyezését Azure-ba vagy másik kiszolgálóra. A teszt feladatátvétel elvégezhető a helyreállítási terven keresztül (több kiszolgáló feladatátvételének összehangolásával) vagy manuálisan egyes VM-eket az Azure konzolon keresztül. 

4. Menedzselés, monitor és hibakeresés

Javasolt a replikációs beállítások folyamatos figyelése annak érdekében, hogy az RPO célok összhangban legyenek. A monitoring történhet például Azure Monitor Logs segítségével, ami gyűjti az aktivitásokat és az erőforrás logokat, valamint egyéb monitoring adatot is tartalmaz. Az Azure Monitoron belül használható a Log Analytics szolgáltatás, amin keresztül log lekérdezések írhatók és tesztelhetők, valamint interaktív módon elemezhetők a log adatok. A vizualizált és lekérdezett log eredményekre beállíthatók alert-ek, amik műveleteket hajtanak végre a monitorozott adatok alapján. 

Összegzés

Az Azure Site Recovery összességében egy nagyszerű szolgáltatás, mely egyszerű és költséghatékony BCDR megoldást kínál az ügyfelek számára. Egy jól meghatározott és megtervezett DRaaS terv biztosítja az üzletmenet folytonosságot és védi a workload-okat a nem tervezett katasztrófa eseményektől. 

 

* RPO (Recovery Point Objective): meghatározza a lehetséges adatmennyiséget (időben mérve), ami elveszthet egy katasztrófa esemény bekövetkeztében.
** RTO (Recovery Time Object): meghatározza, hogy a rendszerek vagy alkalmazások mekkora időkereten belül állíthatók vissza katasztrófa bekövetkezte után.
*** DRaaS (Disaster Recovery as a Service)

Szeretnél többet tudni?

Vedd fel velünk a kapcsolatot az alábbi elérhetőségen:

Sétáló Patrik
Systems Engineer, Microsoft
+36-30/333-1437
Patrik.Setalo@alef.com