Az Azure Storage vészhelyreállításának tervezése és feladatátvétele
A Microsoft arra törekszik, hogy az Azure-szolgáltatások mindig elérhetők legyenek. Előfordulhat azonban, hogy nem tervezett szolgáltatáskimaradások lépnek fel. A jó vészhelyreállítási terv fő összetevői a következőkre vonatkozó stratégiák:
- Adatvédelem
- Biztonsági mentés és visszaállítás
- Adatredundancia
- Feladatátvétel
- Alkalmazások tervezése magas rendelkezésre álláshoz
Ez a cikk a globálisan redundáns tárfiókok (GRS, GZRS és RA-GZRS) feladatátvételét ismerteti, valamint azt, hogy hogyan tervezheti meg az alkalmazásokat magas rendelkezésre állásúnak, ha leállás vagy későbbi feladatátvétel történik.
Válassza ki a megfelelő redundanciabeállítást
Az Azure Storage a tárfiók több példányát is fenntartja a tartósság és a magas rendelkezésre állás biztosítása érdekében. A fiókhoz választott redundancialehetőség az alkalmazásokhoz szükséges rugalmasság mértékétől függ.
Helyileg redundáns tárolás (LRS) esetén a tárfiók három példánya automatikusan egy adatközpontban lesz tárolva és replikálva. A zónaredundáns tárolás (ZRS) esetén a rendszer egy példányt tárol és replikál három különböző rendelkezésre állási zónában ugyanabban a régióban. A rendelkezésre állási zónákkal kapcsolatos további információkért lásd: Azure rendelkezésre állási zónák.
A tárfiók egyetlen példányának helyreállítása automatikusan megtörténik az LRS és a ZRS használatával.
Globálisan redundáns tárolás és feladatátvétel
Globálisan redundáns tárolással (GRS, GZRS és RA-GZRS) az Azure aszinkron módon másolja az adatokat egy másodlagos földrajzi régióba legalább több száz kilométerre. Ez lehetővé teszi az adatok helyreállítását, ha kimaradás van az elsődleges régióban. A globálisan redundáns tárolást az LRS-től és a ZRS-től megkülönböztető funkció a másodlagos régióba történő feladatátvétel lehetősége, ha az elsődleges régióban kimaradás történik. A feladatátvétel folyamata frissíti a tárfiók szolgáltatásvégpontjaiHOZ tartozó DNS-bejegyzéseket, így a másodlagos régió végpontjai lesznek a tárfiók új elsődleges végpontjai. A feladatátvétel befejezése után az ügyfelek megkezdhetik az írást az új elsődleges végpontokra.
Az RA-GRS és az RA-GZRS redundanciakonfigurációk georedundáns tárolást biztosítanak a másodlagos végpont olvasási hozzáférésének további előnyeivel, ha az elsődleges régióban kimaradás történik. Ha leállás történik az elsődleges végponton, a másodlagos régióhoz való olvasási hozzáférésre konfigurált és magas rendelkezésre állásra tervezett alkalmazások továbbra is olvashatnak a másodlagos végpontról. A Microsoft az RA-GZRS használatát javasolja a tárfiókok maximális rendelkezésre állása és tartóssága érdekében.
Az Azure Storage-beli redundanciáról további információt az Azure Storage-redundancia című témakörben talál.
Tárfiók feladatátvételének tervezése
Az Azure Storage-fiókok kétféle feladatátvételt támogatnak:
- Ügyfél által felügyelt feladatátvétel – Az ügyfelek kezelhetik a tárfiók feladatátvételét, ha váratlan szolgáltatáskimaradás történik.
- Microsoft által felügyelt feladatátvétel – Lehetséges, hogy a Microsoft csak súlyos katasztrófa esetén kezdeményezi az elsődleges régióban. 1,2
1A Microsoft által felügyelt feladatátvétel nem kezdeményezhető egyéni tárfiókok, előfizetések vagy bérlők esetében. További részletekért lásd a Microsoft által felügyelt feladatátvételt.
2 A vészhelyreállítási tervnek az ügyfél által felügyelt feladatátvételen kell alapulnia. Ne támaszkodhat a Microsoft által felügyelt feladatátvételre, amelyet csak szélsőséges körülmények között használna.
Minden feladatátvételi típus egyedi használati esetekkel, az adatvesztéssel kapcsolatos elvárásokkal és a hierarchikus névtérrel rendelkező fiókok támogatásával (Azure Data Lake Storage Gen2) rendelkezik. Ez a táblázat a feladatátvétel egyes típusainak ezeket a szempontjait foglalja össze:
| Típus | Feladatátvételi hatókör | Használati eset | Várható adatvesztés | Támogatott HNS |
|---|---|---|---|---|
| Ügyfél által felügyelt | Tárfiók | Az elsődleges régió tárolási szolgáltatásvégpontjai elérhetetlenné válnak, de a másodlagos régió elérhető. Kapott egy Azure Advisory-t, amelyben a Microsoft azt javasolja, hogy végezzen feladatátvételi műveletet azoknak a tárfiókoknak, amelyeket esetleg kimaradás érinthet. |
Igen | Igen (előzetes verzióban) |
| Microsoft által felügyelt | Teljes régió vagy méretezési egység | Az elsődleges régió egy jelentős katasztrófa miatt teljesen elérhetetlenné válik, de a másodlagos régió elérhető. | Igen | Igen |
Ügyfél által felügyelt feladatátvétel
Ha a tárfiókban lévő tárolási szolgáltatások adatvégpontjai elérhetetlenné válnak az elsődleges régióban, feladatátvételt végezhet a másodlagos régióba. A feladatátvétel befejezése után a másodlagos régió lesz az új elsődleges, és a felhasználók hozzáférhetnek az új elsődleges régió adataihoz.
Ha teljes mértékben meg szeretné érteni, hogy az ügyfél által felügyelt fiók feladatátvétele milyen hatással lenne a felhasználókra és az alkalmazásokra, hasznos tudni, hogy mi történik a feladatátvételi és feladat-visszavételi folyamat minden lépése során. A folyamat működésével kapcsolatos részletekért tekintse meg az ügyfél által felügyelt tárfiók feladatátvételének működését.
Microsoft által felügyelt feladatátvétel
Olyan szélsőséges körülmények között, amikor az eredeti elsődleges régiót jelentős katasztrófa miatt ésszerű időn belül helyreállíthatatlannak tekintik, a Microsoft regionális feladatátvételt kezdeményezhet . Ebben az esetben nincs szükség műveletre az Ön részéről. A Microsoft által felügyelt feladatátvétel befejezéséig nem lesz írási hozzáférése a tárfiókhoz. Az alkalmazások akkor olvashatnak a másodlagos régióból, ha a tárfiók RA-GRS-hez vagy RA-GZRS-hez van konfigurálva.
Fontos
A vészhelyreállítási tervnek az ügyfél által felügyelt feladatátvételen kell alapulnia. Ne támaszkodhat a Microsoft által felügyelt feladatátvételre, amely csak szélsőséges körülmények között használható. A Microsoft által felügyelt feladatátvétel egy teljes fizikai egységre, például régióra vagy skálázási egységre lesz elindítva. Nem kezdeményezhető egyéni tárfiókok, előfizetések vagy bérlők esetében. Az egyéni tárfiókok szelektív feladatátvételéhez használja az ügyfél által felügyelt fiók feladatátvételét.
Adatvesztés és inkonzisztenciák előrejelzése
Figyelemfelhívás
A tárfiók feladatátvétele általában némi adatvesztést, esetleg fájl- és adatkonzisztenciát von maga után. A vészhelyreállítási tervben fontos figyelembe venni, hogy a fiók feladatátvétele milyen hatással lenne az adatokra, mielőtt elindítaná az egyiket.
Mivel az adatok aszinkron módon vannak megírva az elsődleges régióból a másodlagos régióba, a rendszer mindig késlelteti az elsődleges régióba történő írást a másodlagos régióba. Ha az elsődleges régió elérhetetlenné válik, előfordulhat, hogy a legutóbbi írások még nem lettek átmásolva a másodlagosra.
Feladatátvétel esetén az elsődleges régió összes adata elveszik, mivel a másodlagos régió lesz az új elsődleges. A feladatátvétel során minden, a másodlagosra másolt adat megmarad. Az elsődlegesre írt, a másodlagos régióba szintén nem másolt adatok azonban végleg elvesznek.
Az új elsődleges régió helyileg redundánsnak (LRS) van konfigurálva a feladatátvétel után.
Fájl- vagy adatkonkonzisztenciát is tapasztalhat, ha a tárfiókok engedélyezve vannak az alábbi lehetőségek közül:
- Hierarchikus névtér (Azure Data Lake Storage Gen2)
- Változáscsatorna
- Időponthoz kötött visszaállítás blokkblobokhoz
Utolsó szinkronizálás ideje
Az Utolsó szinkronizálási idő tulajdonság azt a legutóbbi időpontot jelzi, amikor az elsődleges régió adatai garantáltan a másodlagos régióba lettek beírva. Hierarchikus névtérrel rendelkező fiókok esetében ugyanez a Last Sync Time tulajdonság a hierarchikus névtér által kezelt metaadatokra is vonatkozik, beleértve az ACL-eket is. Az utolsó szinkronizálási idő előtt írt összes adat és metaadat elérhető a másodlagos oldalon, míg az utolsó szinkronizálási idő után írt adatok és metaadatok nem feltétlenül lettek megírva a másodlagosra, és elveszhetnek. Ezt a tulajdonságot akkor használja, ha egy fiók feladatátvételének kezdeményezésével kimaradás történik az esetleges adatvesztés becsléséhez.
Ajánlott eljárásként úgy tervezheti meg az alkalmazást, hogy az utolsó szinkronizálási időt használva kiértékelhesse a várt adatvesztést. Ha például minden írási műveletet naplóz, akkor összehasonlíthatja az utolsó írási műveletek időpontját az utolsó szinkronizálási idővel annak megállapításához, hogy mely írások nincsenek szinkronizálva a másodlagos írással.
Az Utolsó szinkronizálási idő tulajdonság ellenőrzéséről további információt a tárfiók Utolsó szinkronizálási idő tulajdonságának ellenőrzése című témakörben talál.
Az Azure Data Lake Storage Gen2 fájlkonzisztenciája
A hierarchikus névtérrel rendelkező tárfiókok (Azure Data Lake Storage Gen2) replikációja a fájl szintjén történik. Ez azt jelenti, hogy ha az elsődleges régióban leállás történik, lehetséges, hogy a tárolóban vagy könyvtárban lévő fájlok közül csak néhány replikálódott sikeresen a másodlagos régióba. A tárolóban vagy könyvtárban lévő összes fájl konzisztenciája, miután a tárfiók feladatátvétele nem garantált.
Adatcsatorna- és blobadatok inkonzisztenciák módosítása
A változáscsatornával rendelkező georedundáns tárfiókok feladatátvétele következetlenségeket okozhat a változáscsatorna naplói és a blobadatok és/vagy metaadatok között. Az ilyen inkonzisztenciák a változásnaplók frissítéseinek aszinkron jellegéből és a blobadatok elsődlegesről a másodlagos régióba történő replikálására vezethetnek. Az egyetlen olyan helyzet, amelyben nem várható ellentmondás, ha az összes aktuális naplórekord sikeresen ki lett ürítve a naplófájlba, és az összes tárolási adat sikeresen replikálva lett az elsődlegesről a másodlagos régióba.
A változáscsatorna működésével kapcsolatos további információkért lásd a változáscsatorna működését.
Ne feledje, hogy a tárfiók egyéb funkciói megkövetelik a változáscsatorna engedélyezését, például az Azure Blob Storage operatív biztonsági mentését, az objektumreplikálást és a blokkblobok időponthoz kötött visszaállítását.
Időponthoz kötött visszaállítási inkonzisztenciák
Az ügyfél által felügyelt feladatátvételt az általános célú, 2. szintű standard szintű tárfiókok támogatják, amelyek blokkblobokat tartalmaznak. Az ügyfél által felügyelt feladatátvétel egy tárfiókon történő végrehajtása azonban alaphelyzetbe állítja a fiók lehető legkorábbi visszaállítási pontjának visszaállítását. A blokkblobok időponthoz kötött visszaállításának adatai csak a feladatátvétel befejezésének időpontjáig konzisztensek. Ennek eredményeképpen a blokkblobok csak a feladatátvétel befejezési időpontjánál nem korábbi időpontra állíthatók vissza. A feladatátvételi befejezési időt a tárfiók redundancia lapján ellenőrizheti az Azure Portalon.
Tegyük fel például, hogy a megőrzési időtartamot 30 napra állította be. Ha a feladatátvétel óta több mint 30 nap telt el, akkor a 30 napon belül bármely pontra visszaállítható. Ha azonban kevesebb mint 30 nap telt el a feladatátvétel óta, akkor a megőrzési időszaktól függetlenül nem állítható vissza a feladatátvétel előtti pontra. Ha például 10 nap telt el a feladatátvétel óta, akkor a legkorábbi lehetséges visszaállítási pont az elmúlt 10 nap, nem pedig a múlt 30 napja.
A feladatátvétel ideje és költsége
A feladatátvétel elindítása után eltelt idő eltérő lehet, bár általában kevesebb mint egy órát vesz igénybe.
Az ügyfél által felügyelt feladatátvétel a feladatátvétel (és a feladat-visszavétel) után elveszíti a georedundanciát. A rendszer a feladatátvétel során automatikusan helyileg redundáns tárolóvá (LRS) alakítja át a tárfiókot az új elsődleges régióban, és az eredeti elsődleges régióban lévő tárfiók törlődik.
Újra engedélyezheti a georedundáns tárolást (GRS) vagy az olvasási hozzáférésű georedundáns tárolást (RA-GRS) a fiók számára, de vegye figyelembe, hogy az LRS-ről GRS-re vagy RA-GRS-re történő konvertálás további költségekkel jár. A költségek annak köszönhetők, hogy a hálózati kimenő díjak újra replikálják az adatokat az új másodlagos régióba. Emellett az összes archivált blobot újra kell hidratálni egy online szintre, mielőtt a fiók konfigurálható lenne georedundanciára, ami költséggel jár. A díjszabással kapcsolatos további információkért lásd:
Miután újra engedélyezte a GRS-t a tárfiókhoz, a Microsoft megkezdi a fiókban lévő adatok replikálását az új másodlagos régióba. A replikációs idő számos tényezőtől függ, amelyek a következők:
- A tárfiókban lévő objektumok száma és mérete. Sok kis objektum replikálása hosszabb időt vehet igénybe, mint kevesebb és nagyobb objektum replikálása.
- A háttérreplikációs erőforrások, például a CPU, a memória, a lemez és a WAN kapacitás. Az élő forgalom elsőbbséget élvez a georeplikálással szemben.
- Ha a tárfiók blobokat tartalmaz, a pillanatképek száma blobonként.
- Ha a tárfiók táblákat tartalmaz, az adatparticionálási stratégia. A replikációs folyamat nem méretezhető túl a használt partíciókulcsok számán.
Támogatott tárfióktípusok
Minden georedundáns ajánlat támogatja a Microsoft által felügyelt feladatátvételt. Emellett egyes fióktípusok támogatják az ügyfél által felügyelt fiókok feladatátvételét, ahogy az az alábbi táblázatban is látható:
| Feladatátvétel típusa | GRS/RA-GRS | GZRS/RA-GZRS |
|---|---|---|
| Ügyfél által felügyelt feladatátvétel | Általános célú v2-fiókok Általános célú v1-fiókok Örökölt Blob Storage-fiókok |
Általános célú v2-fiókok |
| Microsoft által felügyelt feladatátvétel | Minden fióktípus | Általános célú v2-fiókok |
Klasszikus tárfiókok
Fontos
Az ügyfél által felügyelt fiók feladatátvétele csak az Azure Resource Manager (ARM) üzemi modellel üzembe helyezett tárfiókok esetében támogatott. Az Azure Service Manager (ASM) üzembehelyezési modellje, más néven klasszikus, nem támogatott. Ahhoz, hogy a klasszikus tárfiókok jogosultak legyenek az ügyfél által felügyelt fiókok feladatátvételére, először át kell őket telepíteni az ARM-modellbe. A tárfióknak elérhetőnek kell lennie a frissítés végrehajtásához, így az elsődleges régió jelenleg nem lehet hibás állapotban.
Ha az elsődleges régiót érintő katasztrófa történik, a Microsoft kezeli a klasszikus tárfiókok feladatátvételét. További információ: Microsoft által felügyelt feladatátvétel.
Azure Data Lake Storage Gen2
Fontos
A hierarchikus névtérrel (Azure Data Lake Storage Gen2) rendelkező fiókok ügyfél által felügyelt feladatátvétele jelenleg előzetes verzióban érhető el, és csak a következő régiókban támogatott:
- (Ázsia és a Csendes-óceáni térség) Közép-India
- (Ázsiai-csendes-óceáni térség) Délkelet-Ázsia
- (Európa) Észak-Európa
- (Európa) Észak-Svájc
- (Európa) Nyugat-Svájc
- (Európa) Nyugat-Európa
- (Észak-Amerika) Közép-Kanada
- (Észak-Amerika) USA 2. keleti régiója
- (Észak-Amerika) USA déli középső régiója
Az előzetes verzióra való bejelentkezéshez tekintse meg az Előzetes verziójú szolgáltatások beállítása az Azure-előfizetésben című témakört, és adja meg AllowHNSAccountFailover a funkció nevét.
A bétaverziójú, előzetes verziójú vagy másként még általánosan nem elérhető Azure-szolgáltatások jogi feltételeit lásd: Kiegészítő használati feltételek a Microsoft Azure előzetes verziójú termékeihez.
ha az elsődleges régiót érintő jelentős katasztrófa történik, a Microsoft a hierarchikus névtérrel rendelkező fiókok feladatátvételét fogja kezelni. További információ: Microsoft által felügyelt feladatátvétel.
Nem támogatott funkciók és szolgáltatások
A fiók feladatátvételéhez a következő funkciók és szolgáltatások nem támogatottak:
- Az Azure File Sync nem támogatja az ügyfél által kezdeményezett tárfiók feladatátvételét. Az Azure File Syncben felhővégpontokként használt Azure-fájlmegosztásokat tartalmazó tárfiókokat nem szabad feladatátvételre használni. Feladatátvétel esetén a szinkronizálás leáll, és az újonnan rétegzett fájlok esetében váratlan adatvesztést is okozhat. További információkért lásd az Azure File Sync vészhelyreállításának ajánlott eljárásait.
- A prémium szintű blokkblobokat tartalmazó tárfiókok nem adhatók át. A prémium szintű blokkblobokat támogató tárfiókok jelenleg nem támogatják a georedundanciát.
- Az ügyfél által felügyelt feladatátvétel nem támogatott sem a forrás, sem a célfiók esetében egy objektumreplikációs szabályzatban.
- Ha engedélyezni szeretné az SSH-fájlátviteli protokollt (SFTP) használó fiók feladatátvételét, először le kell tiltania az SFTP-t a fiókhoz. Ha a feladatátvétel befejezése után folytatni szeretné az SFTP használatát, egyszerűen engedélyezze újra.
- A hálózati fájlrendszer (NFS) 3.0 (NFSv3) nem támogatott a tárfiók feladatátvételéhez. Az NFSv3 engedélyezésével nem hozhat létre globális redundanciához konfigurált tárfiókot.
A feladatátvétel nem fiókmigráláshoz szükséges
A tárfiók feladatátvétele nem használható az adatmigrálási stratégia részeként. A feladatátvétel egy szolgáltatáskimaradás ideiglenes megoldása. A tárfiókok migrálásáról további információt az Azure Storage migrálási áttekintésében talál.
Archivált blobokat tartalmazó tárfiókok
Az archivált blobokat tartalmazó tárfiókok támogatják a feladatátvételt. Az ügyfél által felügyelt feladatátvétel befejezése után azonban az összes archivált blobot online szintre kell rehidratálni ahhoz, hogy a fiók konfigurálható legyen a georedundanciára.
Tárolásierőforrás-szolgáltató
A Microsoft két REST API-t biztosít az Azure Storage-erőforrások használatához. Ezek az API-k képezik az Azure Storage-on elvégezhető összes művelet alapját. Az Azure Storage REST API lehetővé teszi, hogy a tárfiókban lévő adatokkal dolgozzon, beleértve a blob-, üzenetsor-, fájl- és táblaadatokat. Az Azure Storage-erőforrás-szolgáltató REST API-val kezelheti a tárfiókot és a kapcsolódó erőforrásokat.
A feladatátvétel befejezése után az ügyfelek ismét olvashatják és írhatnak Azure Storage-adatokat az új elsődleges régióban. Az Azure Storage-erőforrás-szolgáltató azonban nem végzi el a feladatátvételt, ezért az erőforrás-kezelési műveleteknek továbbra is az elsődleges régióban kell lenniük. Ha az elsődleges régió nem érhető el, nem fog tudni felügyeleti műveleteket végrehajtani a tárfiókon.
Mivel az Azure Storage-erőforrás-szolgáltató nem végzi el a feladatátvételt, a Hely tulajdonság az eredeti elsődleges helyet adja vissza a feladatátvétel befejezése után.
Azure-beli virtuális gépek
Az Azure-beli virtuális gépek (VM-ek) nem feladatátvételt a fiók feladatátvétele során. Ha az elsődleges régió elérhetetlenné válik, és a feladatátvétel a másodlagos régióba történik, a feladatátvétel után újra létre kell hoznia a virtuális gépeket. Emellett előfordulhat, hogy a fiók feladatátvételéhez adatvesztés is társul. A Microsoft azt javasolja, hogy kövesse az Azure-beli virtuális gépekre vonatkozó magas rendelkezésre állási és vészhelyreállítási útmutatást.
Ne feledje, hogy az ideiglenes lemezen tárolt adatok elvesznek a virtuális gép leállásakor.
Azure nem felügyelt lemezek
Ajánlott eljárásként a Microsoft azt javasolja, hogy a nem felügyelt lemezeket felügyelt lemezekké alakítsa át. Ha azonban egy azure-beli virtuális gépekhez csatlakoztatott nem felügyelt lemezeket tartalmazó fiók feladatátvételére van szüksége, a feladatátvétel kezdeményezése előtt le kell állítania a virtuális gépet.
A nem felügyelt lemezek lapblobokként vannak tárolva az Azure Storage-ban. Ha egy virtuális gép fut az Azure-ban, a rendszer a virtuális géphez csatlakoztatott nem felügyelt lemezeket bérli. A fiók feladatátvétele nem folytatható, ha bérlet van egy blobon. A feladatátvétel végrehajtásához kövesse az alábbi lépéseket:
- Mielőtt hozzákezdene, jegyezze fel a nem felügyelt lemezek nevét, azok logikai egységszámait (LUN) és azt a virtuális gépet, amelyhez csatolva vannak. Ez megkönnyíti a lemezek újraaktiválását a feladatátvétel után.
- Állítsa le a virtuális gépet.
- Törölje a virtuális gépet, de őrizze meg a nem felügyelt lemezek VHD-fájljait. Figyelje meg, hogy mikor törölte a virtuális gépet.
- Várja meg, amíg az utolsó szinkronizálási idő frissül, és később lesz, mint a virtuális gép törlésének időpontja. Ez a lépés azért fontos, mert ha a másodlagos végpont nem lett teljesen frissítve a VHD-fájlokkal a feladatátvétel során, akkor előfordulhat, hogy a virtuális gép nem működik megfelelően az új elsődleges régióban.
- Indítsa el a fiók feladatátvételét.
- Várjon, amíg a fiók feladatátvétele befejeződött, és a másodlagos régió lett az új elsődleges régió.
- Hozzon létre egy virtuális gépet az új elsődleges régióban, és helyezze újra a virtuális merevlemezeket.
- Indítsa el az új virtuális gépet.
Ne feledje, hogy az ideiglenes lemezen tárolt adatok elvesznek a virtuális gép leállásakor.
Adatok másolása a feladatátvétel alternatívájaként
Ha a tárfiókja a másodlagos régióhoz való olvasási hozzáférésre van konfigurálva, akkor úgy tervezheti meg az alkalmazást, hogy a másodlagos végpontról olvasson. Ha nem szeretne feladatátvételt végezni, ha az elsődleges régióban kimaradás van, az olyan eszközökkel, mint az AzCopy vagy az Azure PowerShell , adatokat másolhat a másodlagos régióban lévő tárfiókból egy másik tárfiókba egy nem érintett régióban. Ezután az alkalmazásokat arra a tárfiókra irányíthatja az olvasási és írási rendelkezésre állás érdekében.
Tervezés magas rendelkezésre álláshoz
Fontos, hogy az alkalmazást a kezdetektől magas rendelkezésre állásra tervezzen. Az alkalmazás megtervezéséhez és a vészhelyreállítás megtervezéséhez az alábbi Azure-erőforrások nyújtanak útmutatást:
- Rugalmas alkalmazások tervezése az Azure-hoz: A magas rendelkezésre állású alkalmazások Azure-beli tervezésének legfontosabb fogalmainak áttekintése.
- Rugalmassági ellenőrzőlista: Ellenőrzőlista annak ellenőrzéséhez, hogy az alkalmazás implementálja-e a magas rendelkezésre álláshoz ajánlott tervezési eljárásokat.
- Georedundancia használata magas rendelkezésre állású alkalmazások tervezéséhez: Tervezési útmutató alkalmazások létrehozásához a georedundáns tárolás előnyeinek kihasználásához.
- Oktatóanyag: Magas rendelkezésre állású alkalmazás létrehozása Blob Storage használatával: Oktatóanyag, amely bemutatja, hogyan hozhat létre magas rendelkezésre állású alkalmazásokat, amelyek automatikusan váltanak a végpontok között a hibák és a helyreállítások szimulálásakor.
Tartsa szem előtt ezeket az ajánlott eljárásokat az Azure Storage-adatok magas rendelkezésre állásának fenntartásához:
- Lemezek: Az Azure Backup használatával készítsen biztonsági másolatot az Azure-beli virtuális gépek által használt virtuálisgép-lemezekről. Érdemes lehet az Azure Site Recoveryt is használni a virtuális gépek védelmére regionális katasztrófa esetén.
- Blokkblobok: Kapcsolja be a helyreállítható törlést az objektumszintű törlés és felülírás elleni védelem érdekében, vagy másolja a blokkblobokat egy másik régióban lévő tárfiókba az AzCopy, az Azure PowerShell vagy az Azure Data Movement könyvtár használatával.
- Fájlok: Az Azure Backup használatával biztonsági másolatot készít a fájlmegosztásokról. Engedélyezze a helyreállítható törlést is, hogy védelmet nyújthasson a véletlen fájlmegosztás-törlésekkel szemben. Georedundancia esetén, ha a GRS nem érhető el, az AzCopy vagy az Azure PowerShell használatával másolhatja a fájlokat egy másik régióban lévő tárfiókba.
- Táblák: táblaadatok exportálása egy másik régióban lévő másik tárfiókba az AzCopy használatával.
Leállások nyomon követése
Az ügyfelek feliratkozhatnak az Azure Service Health irányítópultjára az Azure Storage és más Azure-szolgáltatások állapotának és állapotának nyomon követéséhez.
A Microsoft azt is javasolja, hogy úgy tervezze meg az alkalmazást, hogy fel legyen készülve az esetleges írási hibákra. Az alkalmazásnak úgy kell felfednie az írási hibákat, hogy figyelmeztethessen az elsődleges régióban bekövetkező kimaradás lehetőségére.