Sdílet prostřednictvím

Plánování zotavení po havárii úložiště Azure a proces přepnutí při selhání

  • Článek

Microsoft se snaží zajistit, aby byly služby Azure vždy dostupné. K neplánovaným výpadkům služeb ale může dojít někdy. Mezi klíčové komponenty vhodného plánu zotavení po havárii patří strategie pro:

Tento článek popisuje možnosti dostupné pro geograficky redundantní účty úložiště a poskytuje doporučení pro vývoj vysoce dostupných aplikací a testování plánu zotavení po havárii.

Volba správné možnosti redundance

Azure Storage udržuje několik kopií vašeho účtu úložiště, aby se zajistilo splnění cílů dostupnosti a stálosti, a to i v případě selhání. Způsob replikace dat poskytuje různé úrovně ochrany. Každá možnost nabízí své vlastní výhody, takže možnost, kterou zvolíte, závisí na míře odolnosti, kterou vaše aplikace vyžadují.

Místně redundantní úložiště (LRS), možnost redundance s nejnižšími náklady, automaticky ukládá a replikuje tři kopie vašeho účtu úložiště v rámci jednoho datacentra. I když LRS chrání vaše data před selháním serverového racku a disku, neřeší havárie, jako je požár nebo záplava v datacentru. V případě takových havárií můžou být všechny repliky účtu úložiště nakonfigurované tak, aby používaly LRS, ztraceny nebo neobnovitelné.

Oproti tomu zónově redundantní úložiště (ZRS) uchovává kopii účtu úložiště a replikuje ji v každé ze tří samostatných zón dostupnosti ve stejné oblasti. Další informace o zónách dostupnosti najdete v tématu Zóny dostupnosti Azure.

Geograficky redundantní úložiště a převzetí služeb při selhání

Geograficky redundantní úložiště (GRS), geograficky zónově redundantní úložiště (GZRS) a geograficky zónově redundantní úložiště s přístupem pro čtení (RA-GZRS) jsou příklady geograficky redundantních možností úložiště. Když je nakonfigurované použití geograficky redundantního úložiště (GRS, GZRS a RA-GZRS), Azure data asynchronně zkopíruje do sekundární geografické oblasti. Tyto oblasti se nacházejí stovky nebo dokonce tisíce kilometrů daleko. Tato úroveň redundance umožňuje obnovit data, pokud dojde k výpadku v celé primární oblasti.

Na rozdíl od LRS a ZRS poskytuje geograficky redundantní úložiště také podporu neplánovaného převzetí služeb při selhání sekundární oblasti, pokud dojde k výpadku v primární oblasti. Během procesu přepnutí při selhání se položky DNS (Domain Name System) koncových bodů služby účtu úložiště automaticky aktualizují, aby koncové body sekundární oblasti byly novými primárními koncovými body. Po dokončení neplánovaného převzetí služeb při selhání mohou klienti začít zapisovat do nových primárních koncových bodů.

Geograficky redundantní úložiště jen pro čtení (RA-GRS) a geograficky zónově redundantní úložiště jen pro čtení (RA-GZRS) také poskytují geograficky redundantní úložiště, ale nabízejí další výhodu přístupu pro čtení k sekundárnímu koncovému bodu. Tyto možnosti jsou ideální pro aplikace navržené pro obchodní aplikace s vysokou dostupností, které jsou kritické pro podnikání. Pokud dojde k výpadku primárního koncového bodu, můžou aplikace nakonfigurované pro přístup pro čtení do sekundární oblasti dál fungovat. Microsoft doporučuje RA-GZRS k dosažení maximální dostupnosti a odolnosti vašich úložných účtů.

Další informace o redundanci pro Azure Storage najdete v tématu Redundance služby Azure Storage.

Plán pro přepnutí na záložní systém

Účty Azure Storage podporují tři typy přepnutí při selhání.

1 Převzetí služeb při selhání spravované společností Microsoft nejde zahájit pro jednotlivé účty úložiště, předplatná ani tenanty. Další informace najdete v tématu Převzetí služeb při selhání spravované Microsoftem.
2 Využijte možnosti převzetí služeb řízené zákazníkem k vývoji, testování a implementaci plánů obnovy po havárii. Nespoléhejte na převzetí služeb při selhání, které spravuje Microsoft, a které by se použilo pouze za extrémních okolností.

Každý typ převzetí služeb při selhání má jedinečnou sadu případů použití, očekávanou míru ztráty dat a podporu pro účty s aktivovanou hierarchickou strukturou názvů (Azure Data Lake Storage). Tato tabulka shrnuje aspekty jednotlivých typů přepnutí na záložní systém.

Typ Rozsah převzetí služeb při poruše Případ použití Očekávaná ztráta dat Podporovaný hierarchický jmenný prostor (HNS)
Plánované převzetí při selhání spravované zákazníkem (náhled) Účet úložiště Koncové body služby úložiště pro primární a sekundární oblasti jsou dostupné a chcete provést testování obnovy po havárii.

Koncové body služby úložiště pro primární oblast jsou dostupné, ale jiná služba brání správnému fungování vašich úloh.

Proaktivně se připravit na rozsáhlé katastrofy, jako je hurikán, který by mohl mít vliv na oblast.		 Ne Ano
(V náhledu)
Převzetí služeb při selhání spravované zákazníkem (neplánované) Účet úložiště Koncové body služby úložiště pro primární oblast jsou nedostupné, ale sekundární oblast je dostupná.

Obdrželi jste upozornění Azure, ve kterém vám Microsoft doporučuje provést operaci převzetí služeb při selhání účtů úložiště, které by mohly být ovlivněny výpadkem.		 Ano Yes
Spravovaná Microsoftem Celá oblast Primární oblast přestane být dostupná kvůli významné havárii, ale sekundární oblast je dostupná. Ano Yes

Následující tabulka porovnává stav redundance účtu datového úložiště po každém typu selhání.

Výsledek přepnutí při selhání... Plánované převzetí při selhání spravované zákazníkem (náhled) Převzetí služeb při selhání spravované zákazníkem (neplánované)
... sekundární oblast Sekundární oblast se stane novou primární oblastí. Sekundární oblast se stane novou primární oblastí.
... původní primární oblast Původní primární oblast se stane novou sekundární oblastí. Kopie dat v původní primární oblasti se odstraní.
... konfigurace redundance účtu Účet úložiště se převede na GRS. Účet úložiště se převede na LRS.
... konfigurace geografické redundance Geografická redundance se zachová Geografická redundance se ztratí.

Následující tabulka shrnuje výslednou konfiguraci redundance v každé fázi procesu převzetí služeb při selhání a navrácení služeb po obnovení pro každý typ převzetí služeb při selhání:

Původní
konfigurace		 Po
převzetí služeb při selhání		 Po opětovném povolení
geografická redundance		 Po
obnovení primárního stavu po selhání		 Po opětovném povolení
geografická redundance
Plánované převzetí při selhání spravované zákazníkem
GRS GRS n/a 1 GRS n/a 1
GZRS GRS n/a 1 GZRS n/a 1
Převzetí služeb při selhání spravované zákazníkem (neplánované)
GRS LRS GRS LRS GRS
GZRS LRS GRS ZRS GZRS

1 Geografická redundance zůstává zachována během plánovaného převzetí služeb při selhání a není nutné ji ručně překonfigurovat.

Plánované převzetí při selhání spravované zákazníkem (náhled)

Plánované převzetí služeb při selhání lze využít ve více scénářích, včetně plánovaného testování obnovy po havárii, proaktivního přístupu ke zvládání rozsáhlých pohrom nebo k obnovení provozu po výpadcích nesouvisejících s úložištěm.

Během plánovaného procesu převzetí služeb při selhání se zamění primární a sekundární oblasti. Původní primární oblast se sníží a stane se novou sekundární oblastí. Zároveň se upřednostní původní sekundární oblast a stane se novou primární oblastí. Po dokončení přechodu při selhání mohou uživatelé pokračovat v přístupu k datům v novém primárním regionu a správci systému mohou ověřit svůj plán zotavení po havárii. Před plánovaným přepnutím musí být účet úložiště dostupný v primární i sekundární oblasti.

Během plánovaného procesu převzetí a obnovení po selhání se neočekává ztráta dat, pokud jsou během celého procesu k dispozici primární a sekundární regiony. Další podrobnosti najdete v části Předvídání ztráty dat a nekonzistence .

Abyste pochopili dopad tohoto typu přepnutí na uživatele a aplikace, je užitečné vědět, co se stane během každého kroku plánovaných procesů přepnutí a zpětného přepnutí. Podrobnosti o tom, jak tento proces funguje, najdete v tématu Jak funguje převzetí služeb při selhání plánované a spravované zákazníkem.

Důležité

Plánované převzetí služeb při selhání spravované zákazníkem je aktuálně ve verzi PREVIEW a omezeno na následující oblasti:

  • Východní Asie
  • Southeast Asia
  • Austrálie – východ
  • Austrálie – jihovýchod
  • Francie – střed
  • Francie – jih
  • Střední Indie
  • Indie – západ
  • Švýcarsko – západ
  • Švýcarsko – sever

Pokud se chcete přihlásit k verzi Preview, přečtěte si téma Nastavení funkcí ve verzi Preview v předplatném Azure a jako název funkce zadejte AllowSoftFailover. Název poskytovatele této funkce ve verzi Preview je Microsoft.Storage.

Právní podmínky, které platí pro funkce Azure, které jsou ve verzi beta, verzi Preview nebo které zatím nejsou veřejně dostupné, najdete v Dodatečných podmínkách použití pro Microsoft Azure verze Preview.

Důležité

Po plánovaném převzetí služeb při selhání se může stát, že hodnota LST (Last Sync Time) účtu úložiště se zobrazí jako zastaralá nebo je nahlášena jako NULL (nedefinovaná), pokud jsou přítomna data služby Azure Files.

Snímky systému se pravidelně vytvářejí v sekundární oblasti účtu úložiště k zachování konzistentních bodů obnovení používaných při failoveru a failbacku. Zahájení plánovaného převzetí služeb při selhání spravovaného zákazníkem způsobí, že původní primární region se stane novým sekundárním regionem. V některých případech nejsou po dokončení plánovaného selhání na novém sekundárním systému k dispozici žádné systémové snímky, což způsobuje, že celková hodnota LST účtu se může zdát zastaralá nebo se zobrazí jako Null.

Vzhledem k tomu, že aktivity uživatelů, jako je vytváření, úpravy nebo odstraňování objektů, můžou aktivovat vytváření snímků, nebude vyžadovat další pozornost jakýkoli účet, u kterého tyto aktivity probíhají po plánovaném převzetí služeb při selhání. Účty, které nemají žádné snímky nebo aktivitu uživatelů, ale mohou nadále zobrazovat Null hodnotu LST, dokud se neaktivuje vytvoření snímku systému.

V případě potřeby proveďte jednu z následujících aktivit pro každou sdílenou složku v rámci účtu úložiště, aby se aktivovalo vytvoření snímku. Po dokončení by měl váš účet zobrazit platnou hodnotu LST do 30 minut.

  • Připojte sdílenou složku a otevřete libovolný soubor pro čtení.
  • Nahrajte do sdílené složky testovací nebo ukázkový soubor.

Selhání řízené zákazníkem (neplánované)

Pokud se datové koncové body pro služby úložiště ve vašem účtu úložiště stanou v primární oblasti nedostupnými, můžete zahájit neplánované přepnutí při selhání do sekundární oblasti. Po dokončení převzetí služeb při selhání se sekundární oblast stane novou primární oblastí a uživatelé můžou pokračovat v přístupu k datům v ní.

Abyste pochopili účinek tohoto typu převzetí služeb při selhání na uživatele a aplikace, je užitečné vědět, co se stane během každého kroku neplánovaného převzetí služeb při selhání a zpětného obnovení. Podrobnosti o tom, jak funguje převzetí služeb při selhání spravované zákazníkem (neplánované), najdete v tématu Jak funguje převzetí služeb při selhání spravované zákazníkem (neplánované).

Převzetí služeb při selhání spravované Microsoftem

Microsoft může v extrémních případech zahájit regionální obnovení při selhání, například v případě katastrofy, která ovlivní celý region. Během těchto událostí se nevyžaduje žádná akce na vaší straně. Pokud je váš účet úložiště nakonfigurovaný pro RA-GRS nebo RA-GZRS, můžou vaše aplikace během převzetí služeb při selhání pod správou Microsoftu přistupovat k datům ze sekundární oblasti. Dokud ale nedokončíte proces převzetí služeb při selhání, nemáte přístup k zápisu do svého účtu úložiště.

Důležité

Využijte možnosti převzetí řízeného zákazníkem k vývoji, testování a implementaci plánů pro zotavení po havárii. Nespoléhejte na převzetí služeb při selhání řízené Microsoftem, které může být použito pouze v krajních případech. Převzetí služeb po selhání pod správou Microsoftu by se zahájilo pro celou fyzickou jednotku, jako je oblast nebo datové centrum. Nelze to zahájit pro jednotlivé účty úložiště, předplatná ani nájemce. Pokud potřebujete možnost selektivního převzetí služeb při selhání jednotlivých účtů úložiště, použijte plánované převzetí služeb při selhání spravované zákazníkem.

Předvídání ztráty a nekonzistence dat

Upozornění

Neplánované převzetí služeb při selhání spravované zákazníkem obvykle zahrnuje určitou ztrátu dat a může zavést nekonzistence v souborech a datech. V plánu zotavení po havárii je důležité zvážit dopad, jaký by mělo převzetí služeb při selhání účtu na vaše data, než ho zahájíte.

Vzhledem k tomu, že data se zapisují asynchronně z primární oblasti do sekundární oblasti, je vždy zpoždění před zkopírováním zápisu do primární oblasti do sekundární. Pokud primární oblast přestane být dostupná, je možné, že nejnovější zápisy se ještě nemusí zkopírovat do sekundární oblasti.

Když dojde k neplánovanému přepnutí při selhání, všechna data v primární oblasti jsou ztracena, protože sekundární oblast se stane novou primární. Všechna data, která byla už zkopírována do sekundární oblasti, se zachovají, když dojde k selhání. Všechna data zapsaná do primární oblasti, která ještě v sekundární oblasti neexistují, se však trvale ztratí.

Nová primární oblast je po selhání nakonfigurovaná tak, aby byla místně redundantní (LRS).

Můžete také zaznamenat nekonzistence souborů nebo dat, pokud je u vašich účtů úložiště povolena jedna nebo více následujících možností:

Čas poslední synchronizace

Vlastnost Čas poslední synchronizace označuje poslední čas, kdy byla data z primární oblasti zapsána také do sekundární oblasti. U účtů, které mají hierarchický obor názvů, platí stejná vlastnost čas poslední synchronizace také na metadata spravovaná hierarchickým oborem názvů, včetně seznamů řízení přístupu (ACL). Všechna data a metadata zapsaná před posledním časem synchronizace jsou k dispozici na sekundárním serveru. Naproti tomu data a metadata zapsaná po poslední synchronizaci se ještě nemusí zkopírovat do sekundárního objektu a mohlo by dojít ke ztrátě. Během výpadku použijte tuto vlastnost k odhadu množství ztráty dat, ke které může dojít při zahájení převzetí služeb při selhání účtu.

Osvědčeným postupem je navrhnout aplikaci, abyste mohli použít čas poslední synchronizace k vyhodnocení očekávané ztráty dat. Protokolování všech operací zápisu například umožňuje porovnat časy poslední operace zápisu s časem poslední synchronizace. Tato metoda umožňuje určit, které zápisy ještě nejsou synchronizované se sekundárním serverem a které jsou ohroženy ztrátou.

Další informace o kontrole vlastnosti Čas poslední synchronizace najdete v tématu Kontrola vlastnosti Čas poslední synchronizace pro účet úložiště.

Konzistence souborů pro Azure Data Lake Storage

Replikace pro účty úložiště, které mají povolený hierarchický obor názvů (Azure Data Lake Storage), probíhá na úrovni souboru. Vzhledem k tomu, že replikace probíhá na této úrovni, může výpadek v primární oblasti zabránit úspěšné replikaci některých souborů v kontejneru nebo adresáři do sekundární oblasti. Není zaručena konzistence pro všechny soubory v kontejneru nebo adresáři po selhání účtu úložiště.

Nekonzistence dat změn a dat blobů

Neplánované převzetí služeb při selhání účtů úložiště spravované zákazníkem s povoleným kanálem změn může vést k nekonzistenci mezi protokoly kanálu změn a daty objektů blob a/nebo metadaty. Tyto nekonzistence můžou mít za následek asynchronní povahu aktualizací protokolu změn a replikace dat mezi primárními a sekundárními oblastmi. Nekonzistence můžete předejít provedením následujících opatření:

  • Ujistěte se, že jsou všechny záznamy protokolu zapsány do souborů protokolu.
  • Ujistěte se, že se všechna data úložiště replikují z primární do sekundární oblasti.

Další informace o kanálu změn naleznete v tématu Jak kanál změn funguje.

Mějte na paměti, že další funkce účtu úložiště také vyžadují aktivaci kanálu změn. Mezi tyto funkce patří provozní zálohování služby Azure Blob Storage, replikace objektů blob a obnovení k bodu v čase pro blokové objekty blob.

Nekonzistence při obnovení k určitému časovému bodu

Převzetí služeb při selhání spravované zákazníkem se podporuje pro účty úložiště standardní úrovně verze 2 pro obecné účely, které zahrnují objekty blob bloku. Provedení převzetí služeb při selhání spravované zákazníkem u účtu úložiště však resetuje nejdřívější možný bod obnovení pro účet. Data pro bodové obnovení blokových blobů jsou konzistentní pouze do času dokončení převzetí služeb při selhání. Proto můžete obnovit objekty block blob pouze k určitému bodu v čase, který není dřívější než čas dokončení převzetí služeb při selhání. Čas dokončení převzetí služeb při selhání můžete zkontrolovat v záložce redundance vašeho účtu úložiště na Azure Portalu.

Čas a náklady na failover

Doba, kterou zabere dokončení převzetí služeb po selhání, které je řízené zákazníkem, se může lišit, ačkoliv obvykle nepřesahuje jednu hodinu.

Plánované převzetí služeb při selhání spravované zákazníkem neztrácí svou geografickou redundanci po převzetí a následném návratu do normálu, ale neplánované převzetí služeb při selhání spravované zákazníkem ji ztrácí.

Iniciování neplánovaného převzetí služeb při selhání spravovaného zákazníkem automaticky převede váš účet úložiště na místně redundantní úložiště (LRS) v nové primární oblasti a odstraní účet úložiště v původní primární oblasti.

Pro účet můžete znovu povolit geograficky redundantní úložiště (GRS) nebo geograficky redundantní úložiště jen pro čtení (RA-GRS), ale při opětovné replikaci dat do nové sekundární oblasti je účtován poplatek. Kromě toho musí být všechny archivované objekty blob rehydrované do online vrstvy, aby bylo možné účet překonfigurovat pro geografickou redundanci. Za tuto rehydrataci se také účtují další poplatky. Další informace o cenách najdete tady:

Po opětovném povolení GRS pro účet úložiště začne Microsoft replikovat data ve vašem účtu do nové sekundární oblasti. Doba trvání replikace závisí na několika faktorech. Mezi tyto faktory patří:

  • Počet a velikost objektů v účtu úložiště. Replikace mnoha malých objektů může trvat déle než replikace menšího počtu větších objektů.
  • Dostupné prostředky pro replikaci na pozadí, jako je procesor, paměť, disk a kapacita sítě WAN. Živý provoz má přednost před geografickou replikací.
  • Počet snímků na jeden blob, je-li to relevantní.
  • Strategie dělení dat, pokud váš účet úložiště obsahuje tabulky. Proces replikace se nemůže škálovat nad rámec počtu klíčů oddílů, které používáte.

Podporované typy účtů úložiště

Všechny geograficky redundantní nabídky podporují Microsoftem spravované převzetí služeb při selhání. Některé typy účtů navíc podporují převzetí služeb při selhání účtu spravovaného zákazníkem, jak je znázorněno v následující tabulce:

Typ failoveru GRS/RA-GRS GZRS/RA-GZRS
Plánované převzetí služeb při selhání spravované zákazníkem (Preview) Účty pro obecné účely verze 2
Účty pro obecné účely verze 1
Starší účty Blob Storage		 Účty pro obecné účely verze 2
Převzetí služeb při selhání spravované zákazníkem (neplánované) Účty pro obecné účely verze 2
Účty pro obecné účely verze 1
Starší účty Blob Storage		 Účty pro obecné účely verze 2
Převzetí služeb při selhání spravované společností Microsoft Všechny typy účtů Účty pro obecné účely verze 2

Klasické úložné účty

Důležité

Převzetí služeb při selhání, které je spravováno zákazníkem, se podporuje pouze pro účty úložiště nasazené pomocí modelu nasazení Azure Resource Manager (ARM). Model nasazení Azure Service Manageru (ASM), označovaný také jako klasický model, se nepodporuje. Pokud chcete, aby klasické účty úložiště měly nárok na převzetí služeb při selhání účtu spravovaného zákazníkem, je potřeba je nejprve migrovat do modelu ARM. Abyste mohli provést upgrade, musí být váš účet úložiště přístupný, takže primární oblast momentálně nemůže být ve stavu selhání.

Během katastrofy, která ovlivňuje primární oblast, bude Microsoft spravovat převzetí služeb při selhání klasických účtů úložiště. Další informace najdete v tématu Převzetí služeb při selhání spravované Microsoftem.

Nepodporované funkce a služby

Následující funkce a služby nejsou podporovány pro zákaznicky spravované převzetí služeb při selhání:

  • Synchronizace souborů Azure nepodporuje převzetí služeb při selhání účtu spravovaného zákazníkem. Úložiště účtů používané jako koncové body cloudu pro Azure File Sync by se neměly převzaty při selhání. Přepnutí při selhání naruší synchronizaci souborů a může způsobit nečekanou ztrátu dat u nově hierarchizovaných souborů. Pro více informací si přečtěte podrobnosti v tématu Osvědčené postupy pro zotavení po havárii s Azure File Sync.
  • Účet úložiště, který obsahuje objekty blob bloku premium, nelze přepnout při selhání. Účty úložiště, které podporují prémiové blokové blob objekty, momentálně nepodporují geografickou redundanci.
  • Převzetí služeb při selhání spravované zákazníkem není podporováno ani pro zdrojový, ani pro cílový účet v politice replikace objektů.
  • Převzetí služeb při selhání účtu úložiště nepodporuje systém souborů NFS (Network File System) 3.0 (NFSv3). Nemůžete vytvořit účet úložiště nakonfigurovaný pro geografickou redundanci s povolenou NFSv3.

Následující tabulka se dá použít k referenční podpoře funkcí.

Plánovaný failover Neplánované převzetí služeb
Azure Data Lake Storage Podporováno (Předběžná verze) Podporováno
Záznam změn Nepodporované Podporováno
Replikace objektů Nepodporované Nepodporované
SFTP Podporováno (Předběžná verze) Podporováno
NFSv3 GRS není podporováno. GRS není podporováno.
Akce úložiště Podporováno1 Podporováno1
Obnovení k určitému bodu v čase (PITR) Nepodporované Podporováno

1 Pokud zahájíte zákazníkem řízené plánované nebo neplánované převzetí služeb při selhání, úlohy úložiště nemůžou s účtem fungovat, dokud nedojde k návratu do původní primární oblasti. Další informace.

Záložní režim není určen pro migraci účtu

** Převzetí služeb při selhání účtu úložiště je dočasné řešení používané k vývoji a testování plánů zotavení po havárii nebo k obnově po výpadku služby. Převzetí služeb při selhání by nemělo být používáno jako součást vaší strategie migrace dat. Informace o migraci účtů úložiště najdete v přehledu migrace služby Azure Storage.

Účty obsahující archivované blobové objekty

Účty úložiště obsahující archivované objekty blob podporují převzetí služeb při selhání účtu. Po dokončení převzetí služeb při selhání spravovaného zákazníkem se ale musí všechny archivované objekty blob přesunout do online vrstvy, aby bylo možné účet nakonfigurovat pro geografickou redundanci.

Poskytovatel úložných zdrojů

Microsoft poskytuje dvě rozhraní REST API pro práci s prostředky Azure Storage. Tato rozhraní API tvoří základ všech akcí, které můžete provádět ve službě Azure Storage. Rozhraní REST API služby Azure Storage umožňuje pracovat s daty ve vašem účtu úložiště, včetně dat blobů, front, souborů a tabulek. Rozhraní REST API poskytovatele prostředků Azure Storage umožňuje spravovat účet úložiště a související prostředky.

Po dokončení převzetí služeb při selhání mohou klienti znovu číst a zapisovat data Azure Storage v nové primární oblasti. Poskytovatel prostředků Azure Storage ale nepřevezme služby při selhání, takže operace správy prostředků musí proběhnout v primární oblasti. Pokud primární oblast není dostupná, nebudete moct provádět operace správy v účtu úložiště.

Vzhledem k tomu, že poskytovatel prostředků Azure Storage neprovádí převzetí služeb při selhání, vlastnost Location vrátí původní primární umístění po dokončení převzetí služeb při selhání.

Virtuální počítače Azure

Virtuální počítače Azure nejsou součástí převzetí při selhání účtu úložiště. Všechny virtuální počítače, které byly převzaty do sekundárního regionu v reakci na výpadek, se po dokončení převzetí musí znovu vytvořit. Při převzetí služeb při selhání účtu může dojít ke ztrátě dat uložených na dočasném disku, pokud se virtuální počítač vypne. Microsoft doporučuje postupovat podle pokynů pro vysokou dostupnost a zotavení po havárii specifických pro virtuální počítače v Azure.

Nespravované disky Azure

Nespravované disky se ukládají jako stránkové blobové objekty ve službě Azure Storage. Když je virtuální počítač spuštěný v Azure, všechny nespravované disky připojené k virtuálnímu počítači se zapůjčí. Převzetí služeb při selhání účtu nemůže pokračovat, pokud existuje pronájem na objekt blob. Aby bylo možné zahájit převzetí služeb při selhání u účtu, který obsahuje nespravované disky připojené k virtuálním počítačům Azure, musí být disky vypnuté. Z tohoto důvodu doporučené postupy Microsoftu zahrnují převod všech nespravovaných disků na spravované disky.

Pokud chcete provést převzetí služeb při selhání u účtu obsahujícího nespravované disky, postupujte takto:

  1. Než začnete, poznamenejte si názvy všech nespravovaných disků, jejich logických jednotek (LUN) a virtuálního počítače, ke kterému jsou připojené. Tím usnadníte opětovné připojení disků po přepnutí.
  2. Vypněte virtuální počítač.
  3. Odstraňte virtuální počítač, ale zachovejte soubory virtuálního pevného disku (VHD) pro nespravované disky. Poznamenejte si čas, kdy jste virtuální počítač odstranili.
  4. Počkejte na aktualizaci času poslední synchronizace a ujistěte se, že je pozdější než čas, kdy jste virtuální počítač odstranili. Tento krok zajistí, že při převzetí služeb při selhání budou na sekundárním koncovém bodu plně přítomny soubory VHD a že virtuální počítač bude správně fungovat v nově určené primární oblasti.
  5. Zahajte převzetí služeb při selhání účtu.
  6. Počkejte, až bude dokončeno převzetí služeb při selhání účtu a sekundární oblast se stane novou primární oblastí.
  7. Vytvořte virtuální počítač v nové primární oblasti a znovu připojte virtuální pevné disky.
  8. Spusťte nový virtuální počítač.

Mějte na paměti, že při vypnutí virtuálního počítače dojde ke ztrátě všech dat uložených na dočasném disku.

Přepínání na kopírování dat jako alternativa při selhání

Jak jsme už probírali dříve, můžete vysokou dostupnost udržovat tak, že nakonfigurujete aplikace tak, aby používaly účet úložiště nakonfigurovaný pro přístup pro čtení do sekundární oblasti. Pokud ale nechcete provést failover během výpadku v primárním regionu, můžete data zkopírovat ručně. Nástroje, jako AzCopy a Azure PowerShell, umožňují kopírovat data z účtu úložiště v ovlivněné oblasti do jiného účtu úložiště v neovlivněné oblasti. Po dokončení operace kopírování můžete aplikace překonfigurovat tak, aby používaly účet úložiště v nedotknuté oblasti pro dostupnost čtení i zápisu.

Návrh pro zajištění vysoké dostupnosti

Je důležité navrhnout aplikaci pro zajištění vysoké dostupnosti od začátku. Pokyny k návrhu aplikace a plánování zotavení po havárii najdete v těchto prostředcích Azure:

Informace o zajištění vysoké dostupnosti dat Azure Storage najdete v těchto osvědčených postupech:

  • Disky: Pomocí služby Azure Backup zálohujte disky virtuálních počítačů používané virtuálními počítači Azure. Zvažte také použití Azure Site Recovery k ochraně virtuálních počítačů před regionální havárií.
  • Blokové objekty blob: Zapněte měkké odstranění, abyste chránili proti odstranění a přepsání na úrovni objektů, nebo kopírujte blokové objekty blob do jiného účtu úložiště v jiné oblasti pomocí AzCopy, Azure PowerShellu nebo knihovny Azure Data Movement.
  • Soubory: K zálohování sdílených složek použijte Azure Backup . Také povolte měkké smazání k ochraně proti náhodnému odstranění sdílených souborů. Pokud není geografická redundance dostupná, zkopírujte soubory do jiného účtu úložiště v jiné oblasti pomocí AzCopy nebo Azure PowerShellu .
  • Tabulky: Pomocí Nástroje AzCopy můžete exportovat data tabulky do jiného účtu úložiště v jiné oblasti.

Sledování výpadků

Zákazníci se můžou přihlásit k odběru řídicího panelu služby Azure Service Health a sledovat stav služby Azure Storage a dalších služeb Azure.

Microsoft také doporučuje navrhnout aplikaci tak, aby byla připravena na možnost selhání zápisu. Vaše aplikace by měla upozornit na chyby zápisu takovým způsobem, abyste byli včas informováni o možném výpadku v primární oblasti.

Viz také