Helyreállítás egész régióra kiterjedő szolgáltatáskimaradás esetén

Az Azure fizikailag és logikailag régióknak nevezett egységekre van osztva. Egy régió egy vagy több, egymáshoz közel lévő adatközpontból áll. Számos régió és szolgáltatás támogatja a rendelkezésre állási zónákat is, amelyek nagyobb rugalmasságot biztosítanak a szolgáltatáskimaradásokkal szemben egyetlen adatközpontban. Fontolja meg a rendelkezésre állási zónákkal rendelkező régiók használatát a megoldás rendelkezésre állásának javításához.

Ritka körülmények között előfordulhat, hogy egy teljes rendelkezésre állási zónában vagy régióban lévő létesítmények elérhetetlenné válhatnak, például hálózati hibák miatt. Vagy a létesítmények teljesen elveszhetnek, például egy természeti katasztrófa miatt. Az Azure olyan alkalmazásokat hozhat létre, amelyek zónák és régiók között vannak elosztva. Az ilyen elosztás segít minimalizálni annak lehetőségét, hogy az egyik zónában vagy régióban bekövetkező hiba más zónákat vagy régiókat is érinthet.

Felhőszolgáltatások

Erőforrás-kezelés

A számítási példányok régiók közötti elosztásához hozzon létre egy külön felhőszolgáltatást az egyes célrégiókban, majd tegye közzé az üzembehelyezési csomagot az egyes felhőszolgáltatásokban. A különböző régiókban lévő felhőszolgáltatások közötti forgalomelosztást azonban az alkalmazásfejlesztőnek vagy egy forgalomkezelési szolgáltatásnak kell megvalósítania.

A kapacitástervezés fontos eleme a vészhelyreállítás előtt üzembe helyezendő tartalék szerepkörpéldányok számának meghatározása. A teljes körű másodlagos üzembe helyezés biztosítja, hogy szükség esetén már rendelkezésre álljon a kapacitás; ez azonban gyakorlatilag megkétszerezi a költségeket. Gyakran előfordul, hogy egy kis, másodlagos üzembe helyezéssel rendelkezik, amely elég nagy a kritikus szolgáltatások futtatásához. Ez a kis méretű másodlagos üzembe helyezés jó ötlet mind a kapacitás lefoglalásához, mind a másodlagos környezet konfigurációjának teszteléséhez.

Megjegyzés

Az előfizetési kvóta nem kapacitásgarancia. A kvóta egyszerűen egy kreditkorlát. A kapacitás garantálásához meg kell határozni a szükséges számú szerepkört a szolgáltatásmodellben, és telepíteni kell a szerepköröket.

Terheléselosztás

A régiók közötti forgalom terheléselosztásához forgalomkezelési megoldásra van szükség. Az Azure biztosítja az Azure Traffic Managert. Olyan külső szolgáltatások is kihasználhatók, amelyek hasonló forgalomkezelési képességeket biztosítanak.

Stratégiák

Számos alternatív stratégia érhető el az elosztott számítási feladatok régiók közötti implementálására. Ezeket az alkalmazás konkrét üzleti igényeihez és körülményeihez kell igazítani. Magas szinten a megközelítések a következő kategóriákba sorolhatók:

• Ismételt üzembe helyezés katasztrófa esetén: Ebben a megközelítésben az alkalmazást a katasztrófa idején az alapoktól újra üzembe helyezik. Ez olyan nem kritikus alkalmazások esetében megfelelő, amelyek nem igényelnek garantált helyreállítási időt.

• Meleg tartalék (aktív/passzív): Másodlagos üzemeltetett szolgáltatás jön létre egy másik régióban, és a szerepkörök a minimális kapacitás garantálása érdekében vannak üzembe helyezve; A szerepkörök azonban nem kapják meg az éles forgalmat. Ez a megközelítés olyan alkalmazások esetében hasznos, amelyeket nem a régiók közötti forgalom elosztására terveztek.

• Gyakori elérésű tartalék (aktív/aktív): Az alkalmazás úgy lett kialakítva, hogy több régióban is megkapja az éles terhelést. Előfordulhat, hogy az egyes régiókban a felhőszolgáltatások a vészhelyreállításhoz szükségesnél nagyobb kapacitásra vannak konfigurálva. Alternatív megoldásként a felhőszolgáltatások szükség szerint felskálázhatók egy katasztrófa idején, és feladatátvételt hajthatnak végre. Ez a megközelítés jelentős befektetést igényel az alkalmazástervezésbe, de jelentős előnyökkel jár. Ezek közé tartozik az alacsony és garantált helyreállítási idő, az összes helyreállítási hely folyamatos tesztelése és a kapacitás hatékony kihasználtsága.

Az elosztott kialakítás teljes körű megvitatása a dokumentum hatókörén kívül esik. További információ: Vészhelyreállítás és magas rendelkezésre állás azure-alkalmazásokhoz.

Virtual machines (Virtuális gépek)

A szolgáltatott infrastruktúra (IaaS) virtuális gépek (VM-ek) helyreállítása sok szempontból hasonlít a szolgáltatásként nyújtott platform (PaaS) számítási helyreállításához. Vannak azonban fontos különbségek, mivel az IaaS virtuális gép a virtuális gépből és a virtuálisgép-lemezből is áll.

• A Azure Backup használatával alkalmazáskonzisztens régiók közötti biztonsági mentéseket hozhat létre. Azure Backup lehetővé teszi az ügyfelek számára, hogy alkalmazáskonzisztens biztonsági mentéseket hozzanak létre több virtuálisgép-lemezen, és támogassák a biztonsági másolatok régiók közötti replikálását. Ehhez válassza a biztonsági mentési tároló georeplikációját a létrehozáskor. A biztonsági mentési tároló replikációját a létrehozáskor kell konfigurálni. Később nem állítható be. Ha egy régió elveszik, a Microsoft elérhetővé teszi a biztonsági másolatokat az ügyfelek számára. Az ügyfelek bármely konfigurált visszaállítási pontra vissza tudnak majd állítani.

• Válassza el az adatlemezt az operációsrendszer-lemeztől. Az IaaS virtuális gépek egyik fontos szempontja, hogy a virtuális gép újbóli létrehozása nélkül nem módosíthatja az operációsrendszer-lemezt. Ez nem jelent problémát, ha a helyreállítási stratégia a katasztrófa utáni ismételt üzembe helyezés. Ez azonban problémát jelenthet, ha a warm spare megközelítést használja a kapacitás lefoglalásához. A megfelelő implementáláshoz a megfelelő operációsrendszer-lemezt kell üzembe helyeznie az elsődleges és a másodlagos helyeken is, és az alkalmazásadatokat külön meghajtón kell tárolni. Ha lehetséges, használjon szabványos operációsrendszer-konfigurációt, amely mindkét helyen elérhető. A feladatátvételt követően csatlakoztatnia kell az adatmeghajtót a másodlagos tartományvezérlő meglévő IaaS virtuális gépeihez. Az AzCopy használatával az adatlemez(ek) pillanatképeit egy távoli helyre másolhatja.

• Vegye figyelembe a lehetséges konzisztenciaproblémákat több virtuálisgép-lemez geo-feladatátvétele után. A virtuálisgép-lemezek Azure Storage-blobokként vannak implementálva, és ugyanazzal a georeplikációs jellemzővel rendelkeznek. A Azure Backup használata nélkül nincs garancia a lemezek közötti konzisztenciára, mivel a georeplikáció aszinkron, és egymástól függetlenül replikál. Az egyes virtuálisgép-lemezek garantáltan összeomlás-konzisztens állapotban vannak a geo-feladatátvétel után, de nem konzisztensek a lemezek között. Ez bizonyos esetekben problémákat okozhat (például lemezcsíkozás esetén).

• Az Azure Site Recovery használatával régiók közötti alkalmazásokat replikálhat. Az Azure Site Recovery esetében az ügyfeleknek nem kell aggódniuk az adatlemezek operációsrendszer-lemezektől való elkülönítése vagy a lehetséges konzisztenciaproblémák miatt. Az Azure Site Recovery replikálja a fizikai és virtuális gépeken futó számítási feladatokat egy elsődleges helyről (akár a helyszínen, akár az Azure-ban) egy másodlagos helyre (az Azure-ban). Ha kimaradás történik az ügyfél elsődleges helyén, feladatátvétel aktiválható, hogy gyorsan vissza lehessen adni az ügyfelet egy működési állapotba. Az elsődleges hely visszaállítása után az ügyfelek feladat-visszavételt végezhetnek. Az alkalmazáskonzisztens pillanatképekkel egyszerűen replikálhatók helyreállítási pontok használatával. Ezek a pillanatképek lemezadatokat, memórián belüli adatokat és minden folyamatban lévő tranzakciót rögzítenek. Az Azure Site Recovery lehetővé teszi az ügyfelek számára, hogy a helyreállítási időkorlátokat (RTO) és a helyreállítási időkorlátokat (RPO) a szervezeti korlátokon belül tartsák. Az ügyfelek emellett egyszerűen futtathatnak vészhelyreállítási próbákat anélkül, hogy hatással vannak az éles alkalmazásokra. Helyreállítási tervek használatával az ügyfelek több virtuális gépen futó többfunkciós alkalmazások feladatátvételét és helyreállítását is sorba rendezhetik. Egy helyreállítási tervben csoportosíthatják a gépeket, és opcionálisan szkripteket és manuális műveleteket is hozzáadhatnak. A helyreállítási tervek integrálhatók Azure Automation runbookokkal.

Tárolás

Helyreállítás blobok, táblák, üzenetsorok és virtuálisgép-lemezek georedundáns tárolójának használatával

Az Azure-ban a blobok, táblák, üzenetsorok és virtuálisgép-lemezek alapértelmezés szerint georeplikálva vannak. Ezt georedundáns tárolásnak (GRS) nevezzük. A GRS egy adott földrajzi régión belül több száz mérföld távolságra található párosított adatközpontba replikálja a tárolási adatokat. A GRS-t úgy tervezték, hogy nagyobb adatközpont-katasztrófa esetén további tartósságot biztosítson. A Microsoft szabályozza a feladatátvételt, és a feladatátvétel olyan súlyos katasztrófákra korlátozódik, amelyekben az eredeti elsődleges helyet ésszerű időn belül helyreállíthatatlannak tekintik. Bizonyos esetekben ez több nap is lehet. Az adatok replikálása általában néhány percen belül megtörténik, bár a szinkronizálási időközre még nem vonatkozik szolgáltatásiszint-szerződés.

Geo-feladatátvétel esetén a fiók elérésének módja nem változik (az URL-cím és a fiókkulcs nem változik). A tárfiók azonban a feladatátvételt követően egy másik régióban lesz. Ez hatással lehet azokra az alkalmazásokra, amelyek regionális affinitást igényelnek a tárfiókjukkal. Még az olyan szolgáltatások és alkalmazások esetében is, amelyek nem igényelnek tárfiókot ugyanabban az adatközpontban, az adatközpontok közötti késés és a sávszélesség-díjak kényszerítő okok lehetnek a forgalom feladatátvételi régióba való ideiglenes áthelyezéséhez. Ez figyelembe vehet egy átfogó vészhelyreállítási stratégiát.

A GRS által biztosított automatikus feladatátvétel mellett az Azure bevezetett egy szolgáltatást, amely olvasási hozzáférést biztosít az adatok másolatához a másodlagos tárolási helyen. Ezt írásvédett georedundáns tárolásnak (RA-GRS) nevezzük.

További információ a GRS-ről és az RA-GRS-tárolóról: Azure Storage-replikáció.

Georeplikációs régióleképezések

Fontos tudni, hogy hol vannak georeplikálva az adatok, hogy tudja, hol helyezze üzembe az adatok más olyan példányait, amelyek regionális affinitást igényelnek a tárolóhoz. További információ: Párosított Azure-régiók.

Georeplikáció díjszabása

A georeplikációt az Azure Storage jelenlegi díjszabása tartalmazza. Ezt georedundáns tárolásnak (GRS) nevezzük. Ha nem szeretné az adatok georeplikációját, letilthatja a georeplikációt a fiókjában. Ezt helyileg redundáns tárolásnak (LRS) nevezik, és a GRS-hez képest kedvezményes áron számítjuk fel.

Annak megállapítása, hogy történt-e geo-feladatátvétel

Geo-feladatátvétel esetén ez megjelenik az Azure Service Health irányítópultján. Az alkalmazások azonban a tárfiókjuk georégiójának figyelésével automatizálhatják ennek észlelését. Ez más helyreállítási műveletek indítására is használható, például a számítási erőforrások aktiválására abban a földrajzi régióban, ahová a tárolójuk átkerült. Ehhez a szolgáltatásfelügyeleti API-ból végezhet lekérdezést a Tárfiók tulajdonságainak lekérése paranccsal. A vonatkozó tulajdonságok a következők:

<GeoPrimaryRegion>primary-region</GeoPrimaryRegion>
<StatusOfPrimary>[Available|Unavailable]</StatusOfPrimary>
<LastGeoFailoverTime>DateTime</LastGeoFailoverTime>
<GeoSecondaryRegion>secondary-region</GeoSecondaryRegion>
<StatusOfSecondary>[Available|Unavailable]</StatusOfSecondary>

Adatbázis

SQL Database

Azure SQL Database kétféle helyreállítást biztosít: georedundáns visszaállítást és aktív georeplikációt.

Georedundáns visszaállítás

A georedundáns visszaállítás alapszintű, standard és prémium szintű adatbázisokkal is elérhető. Az alapértelmezett helyreállítási lehetőséget biztosítja, ha az adatbázis nem érhető el egy incidens miatt abban a régióban, ahol az adatbázist üzemeltetik. Az időponthoz kötött visszaállításhoz hasonlóan a georedundáns Azure Storage adatbázis-biztonsági mentéseire támaszkodik. A georeplikált biztonsági másolatból áll vissza, ezért rugalmas az elsődleges régióban lévő tárkimaradásokkal szemben. További információ: Azure SQL-adatbázis visszaállítása vagy feladatátvétel másodlagosra.

Aktív georeplikáció

Az aktív georeplikáció minden adatbázisszinten elérhető. Olyan alkalmazásokhoz tervezték, amelyek a georedundáns visszaállításnál agresszívebb helyreállítási követelményeket támasztanak. Az aktív georeplikáció használatával legfeljebb négy olvasható másodpéldányt hozhat létre a különböző régiókban lévő kiszolgálókon. A feladatátvételt bármelyik másodsorban kezdeményezheti. Az aktív georeplikáció emellett az alkalmazásfrissítési vagy áthelyezési forgatókönyvek, valamint az írásvédett számítási feladatok terheléselosztásának támogatására is használható. További információ: Aktív georeplikáció konfigurálása Azure SQL adatbázishoz, és feladatátvétel kezdeményezése. Az alkalmazások és alkalmazások állásidő nélküli frissítésének tervezéséről és implementálásáról az SQL Database aktív georeplikáció használatával a globálisan elérhető szolgáltatások tervezése Azure SQL adatbázis használatával és a felhőalkalmazások működés közbeni frissítéseinek kezelése című témakörben olvashat.

SQL Server az Azure Virtual Machines szolgáltatásban

Az Azure Virtual Machines-ben futó SQL Server 2012-ben (és újabb verziókban) számos lehetőség áll rendelkezésre a helyreállításhoz és a magas rendelkezésre álláshoz. További információ: Magas rendelkezésre állás és vészhelyreállítás az Azure Virtual Machines SQL Server esetén.

Egyéb Azure-platformszolgáltatások

Amikor több Azure-régióban próbálja futtatni a felhőszolgáltatást, figyelembe kell vennie az egyes függőségekre gyakorolt hatásokat. A következő szakaszokban a szolgáltatásspecifikus útmutató feltételezi, hogy ugyanazt az Azure-szolgáltatást kell használnia egy másik Azure-adatközpontban. Ez magában foglalja a konfigurációs és az adatreplikációs feladatokat is.

Megjegyzés

Bizonyos esetekben ezek a lépések segíthetnek a szolgáltatásspecifikus kimaradások elhárításában a teljes adatközpont-esemény helyett. Az alkalmazás szempontjából a szolgáltatásspecifikus kimaradások ugyanolyan korlátozottak lehetnek, és ideiglenesen át kell telepíteni a szolgáltatást egy másik Azure-régióba.

Service Bus

Azure Service Bus olyan egyedi névteret használ, amely nem terjed ki az Azure-régiókra. Az első követelmény tehát a szükséges service bus-névterek beállítása az alternatív régióban. A várólistán lévő üzenetek tartósságára azonban megfontolandó szempontok is vannak. Az üzenetek Azure-régiók közötti replikálására számos stratégia létezik. Ezekről a replikációs stratégiákról és más vészhelyreállítási stratégiákról az alkalmazások Service Bus-kimaradások és vészhelyzetek elleni szigetelésére vonatkozó ajánlott eljárások című témakörben olvashat.

App Service

Ha egy Azure App Service alkalmazást( például Web Apps vagy Mobile Appst) egy másodlagos Azure-régióba szeretne migrálni, rendelkeznie kell a közzétételhez elérhető webhely biztonsági másolatával. Ha a szolgáltatáskimaradás nem érinti a teljes Azure-adatközpontot, előfordulhat, hogy az FTP használatával letölti a webhely tartalmának legutóbbi biztonsági másolatát. Ezután hozzon létre egy új alkalmazást az alternatív régióban, hacsak korábban nem tette ezt meg a kapacitás lefoglalásához. Tegye közzé a webhelyet az új régióban, és végezze el a szükséges konfigurációs módosításokat. Ezek a módosítások tartalmazhatnak adatbázis-kapcsolati sztringeket vagy más régióspecifikus beállításokat. Ha szükséges, adja hozzá a webhely SSL-tanúsítványát, és módosítsa a DNS CNAME rekordot, hogy az egyéni tartománynév az újra üzembehelyezett Azure Web App URL-címre mutassa.

HDInsight

A HDInsighthoz társított adatok alapértelmezés szerint a Azure Blob Storage tárolódnak. A HDInsight megköveteli, hogy a MapReduce-feladatokat feldolgozó Hadoop-fürtöt ugyanabban a régióban kell áthelyezni, mint az elemezni kívánt adatokat tartalmazó tárfiókot. Ha az Azure Storage számára elérhető georeplikációs funkciót használja, az adatokat abban a másodlagos régióban érheti el, ahol az adatok replikálva lettek, ha valamilyen okból az elsődleges régió már nem érhető el. Létrehozhat egy új Hadoop-fürtöt abban a régióban, ahol az adatok replikálva lettek, és folytathatja a feldolgozást.

SQL Reporting

Az Azure-régió elvesztéséből való helyreállításhoz jelenleg több SQL Reporting példányra van szükség a különböző Azure-régiókban. Ezeknek a SQL Reporting példányoknak ugyanazokhoz az adatokhoz kell hozzáférniük, és az adatoknak saját helyreállítási tervvel kell rendelkezniük katasztrófa esetén. Az RDL-fájl külső biztonsági másolatait is fenntarthatja az egyes jelentésekhez.

Media Services

Az Azure Media Services más helyreállítási megközelítéssel rendelkezik a kódoláshoz és a streameléshez. A streamelés általában kritikusabb a regionális kimaradások során. Ennek előkészítéséhez rendelkeznie kell egy Media Services-fiókkal két különböző Azure-régióban. A kódolt tartalomnak mindkét régióban kell lennie. Hiba esetén átirányíthatja a streamelt forgalmat a másik régióba. A kódolás bármely Azure-régióban elvégezhető. Ha a kódolás időérzékeny, például az élő esemény feldolgozása során, a hibák során fel kell készülnie arra, hogy feladatokat küldjön egy másik adatközpontba.

Virtuális hálózat

A konfigurációs fájlok biztosítják a leggyorsabb módot egy virtuális hálózat beállítására egy másik Azure-régióban. Miután konfigurálta a virtuális hálózatot az elsődleges Azure-régióban, exportálja az aktuális hálózat virtuális hálózati beállításait egy hálózati konfigurációs fájlba. Ha kimaradás történik az elsődleges régióban, állítsa vissza a virtuális hálózatot a tárolt konfigurációs fájlból. Ezután konfiguráljon más felhőszolgáltatásokat, virtuális gépeket vagy létesítmények közötti beállításokat az új virtuális hálózattal való együttműködéshez.
Vannak VNET-hez kapcsolódó erőforrások, amelyeket figyelembe kell vennünk (például NSG, DNS, útvonaltáblák). Az Infrastruktúra kódként című szakaszban leírt módszer segítségével minden alkalommal létrehozhatja ugyanazt a környezetet, és üzembe helyezheti egy új régióban.

Ellenőrzőlisták vészhelyreállításhoz

Cloud Services ellenőrzőlista

1. Tekintse át a dokumentum Cloud Services szakaszát.
2. Hozzon létre egy régiók közötti vészhelyreállítási stratégiát.
3. Megismerheti a kapacitások alternatív régiókban való lefoglalásával való kompromisszumokat.
4. Használjon forgalomirányítási eszközöket, például az Azure Traffic Managert.

Virtual Machines ellenőrzőlista

1. Tekintse át a dokumentum Virtual Machines szakaszát.
2. A Azure Backup használatával alkalmazáskonzisztens biztonsági mentéseket hozhat létre a régiók között.

Tárolási ellenőrzőlista

1. Tekintse át a dokumentum Storage szakaszát.
2. Ne tiltsa le a tárolási erőforrások georeplikációját.
3. A georeplikáció alternatív régióinak megismerése feladatátvétel esetén.
4. Egyéni biztonsági mentési stratégiák létrehozása a felhasználó által felügyelt feladatátvételi stratégiákhoz.

SQL Database ellenőrzőlista

1. Tekintse át a dokumentum SQL Database szakaszát.
2. Szükség szerint georedundáns visszaállítást vagy georeplikációt használjon.

SQL Server Virtual Machines ellenőrzőlistáján

1. Tekintse át a dokumentum Virtual Machines szakaszában található SQL Server.
2. Használjon régiók közötti AlwaysOn rendelkezésre állási csoportokat vagy adatbázis-tükrözést.
3. Másik lehetőségként használja a biztonsági mentést és a visszaállítást a Blob Storage-ba.

Service Bus ellenőrzőlista

1. Tekintse át a dokumentum Service Bus szakaszát.
2. Konfiguráljon egy Service Bus-névteret egy másik régióban.
3. Fontolja meg a régiók közötti üzenetek egyéni replikációs stratégiáit.

App Service ellenőrzőlista

1. Tekintse át a dokumentum App Service szakaszát.
2. Az elsődleges régión kívüli helyek biztonsági mentésének karbantartása.
3. Ha a szolgáltatáskimaradás részleges, próbálja meg lekérni az aktuális helyet FTP-vel.
4. Tervezze meg, hogy a helyet egy másik régióban lévő új vagy meglévő helyre helyezi üzembe.
5. Tervezze meg az alkalmazás- és DNS CNAME-rekordok konfigurációs módosításait.

HDInsight ellenőrzőlista

1. Tekintse át a dokumentum HDInsight szakaszát.
2. Hozzon létre egy új Hadoop-fürtöt a régióban replikált adatokkal.

SQL Reporting ellenőrzőlista

1. Tekintse át a dokumentum SQL Reporting szakaszát.
2. Másik SQL Reporting példány karbantartása egy másik régióban.
3. Hozzon létre egy külön tervet a cél régióba való replikálásához.

Media Services ellenőrzőlista

1. Tekintse át a dokumentum Media Services szakaszát.
2. Hozzon létre egy Media Services-fiókot egy másik régióban.
3. Azonos tartalom kódolása mindkét régióban a streamelési feladatátvétel támogatásához.
4. Ha szolgáltatáskimaradás történik, küldjön kódolási feladatokat egy másik régióba.

Virtual Network ellenőrzőlista

1. Tekintse át a dokumentum Virtual Network szakaszát.
2. Exportált virtuális hálózati beállítások használatával hozza létre újra egy másik régióban.