Sdílet prostřednictvím

Zotavení po havárii a převzetí služeb při selhání pro Azure Files

  • Č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 a měli byste mít plán zotavení po havárii (DR) pro zpracování regionálního výpadku služby. Důležitou součástí plánu zotavení po havárii je příprava na převzetí služeb při selhání sekundárního koncového bodu v případě nedostupnosti primárního koncového bodu. Tento článek popisuje koncepty a procesy související s zotavením po havárii (DR) a převzetím služeb při selhání účtu úložiště.

Důležité

Synchronizace souborů Azure podporuje pouze převzetí služeb při selhání účtu úložiště, pokud je služba synchronizace úložiště také převzetí služeb při selhání. Důvodem je to, že Synchronizace souborů Azure vyžaduje, aby účet úložiště a služba synchronizace úložiště byly ve stejné oblasti Azure. Pokud dojde k převzetí služeb při selhání jenom účtu úložiště, operace synchronizace a vrstvení cloudu selžou, dokud služba synchronizace úložiště nepřejde do sekundární oblasti. Pokud chcete převzít služby při selhání účtu úložiště obsahujícího sdílené složky Azure, které se používají jako koncové body cloudu v Synchronizace souborů Azure, přečtěte si Synchronizace souborů Azure osvědčené postupy zotavení po havárii a Synchronizace souborů Azure obnovení serveru.

Metriky obnovení a náklady

Aby organizace formulovala efektivní strategii zotavení po havárii, musí pochopit:

  • Kolik dat si může dovolit ztratit v případě přerušení (cíl bodu obnovení nebo cíl bodu obnovení)
  • Jak rychle musí být schopná obnovit obchodní funkce a data (cíl doby obnovení nebo RTO)

Náklady na zotavení po havárii se obecně zvyšují s nižším nebo nulovým RPO/RTO. Společnosti, které musí být v provozu během několika sekund po havárii a nemohou udržet žádnou ztrátu dat, budou platit více za zotavení po havárii, zatímco ti s vyššími čísly RPO/RTO budou platit méně. Azure poskytuje řešení, která můžou pracovat s různými požadavky cíle bodu obnovení (RPO) a RTO.

Volba správné možnosti redundance

Azure Files nabízí různé možnosti redundance, které chrání vaše data před plánovanými a neplánovanými událostmi, od přechodných selhání hardwaru, výpadků sítě a napájení až po přírodní katastrofy. Všechny sdílené složky Azure můžou používat místně redundantní (LRS) nebo zónově redundantní úložiště (ZRS). Další informace najdete v tématu Redundance služby Azure Files.

Azure Files podporuje převzetí služeb při selhání účtu pro účty úložiště úrovně Standard nakonfigurované s geograficky redundantním úložištěm (GRS) a geograficky zónově redundantním úložištěm (GZRS) pro ochranu před oblastními výpadky. Při selhání účtu můžete zahájit proces převzetí služeb při selhání pro váš účet úložiště, pokud primární koncový bod přestane být dostupný. Převzetí služeb při selhání aktualizuje sekundární koncový bod, aby se stal primárním koncovým bodem vašeho účtu úložiště. Po dokončení převzetí služeb při selhání mohou klienti začít zapisovat do nového primárního koncového bodu.

GRS a GZRS stále riskují ztrátu dat, protože se data kopírují do sekundární oblasti asynchronně, což znamená, že před zkopírováním zápisu do primární oblasti do sekundární oblasti dochází ke zpoždění. V případě výpadku se operace zápisu do primárního koncového bodu, který ještě nebyl zkopírován do sekundárního koncového bodu, ztratí. To znamená, že selhání, které ovlivňuje primární oblast, může vést ke ztrátě dat, pokud primární oblast nejde obnovit. Interval mezi nejnovějšími zápisy do primární oblasti a posledním zápisem do sekundární oblasti je cíl bodu obnovení. Služba Azure Files obvykle obsahuje cíl bodu obnovení 15 minut nebo méně, přestože v současné době neexistuje žádná smlouva SLA o tom, jak dlouho trvá replikace dat do sekundární oblasti.

Důležité

U sdílených složek Azure úrovně Premium se nepodporuje GRS/GZRS. Můžete ale synchronizovat mezi dvěma sdílenými složkami Azure, abyste dosáhli geografické redundance.

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:

Doporučujeme také navrhnout aplikaci tak, aby se připravila 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.

Osvědčeným postupem je navrhnout aplikaci, aby zkontrolovala vlastnost Čas poslední synchronizace a vyhodnotila očekávanou ztrátu dat. Pokud například protokolujete všechny operace zápisu, můžete porovnat čas poslední operace zápisu s časem poslední synchronizace a určit, které zápisy nebyly synchronizovány do sekundární.

Sledování výpadků

Můžete se přihlásit k odběru řídicího panelu služby Azure Service Health a sledovat stav služby Azure Files a dalších služeb Azure.

Vysvětlení procesu převzetí služeb při selhání účtu

Převzetí služeb při selhání účtu spravovaného zákazníkem umožňuje selhání celého účtu úložiště do sekundární oblasti, pokud z nějakého důvodu nebude primární účet dostupný. Když vynutíte převzetí služeb při selhání do sekundární oblasti, klienti můžou po dokončení převzetí služeb při selhání začít zapisovat data do sekundárního koncového bodu. Převzetí služeb při selhání obvykle trvá přibližně hodinu. Před zahájením převzetí služeb při selhání účtu doporučujeme co nejvíce pozastavit úlohu.

Informace o tom, jak zahájit převzetí služeb při selhání účtu, najdete v tématu Zahájení převzetí služeb při selhání účtu.

Jak funguje převzetí služeb při selhání

Za normálních okolností klient zapisuje data do účtu úložiště v primární oblasti a tato data se kopírují asynchronně do sekundární oblasti. Následující obrázek ukazuje scénář, kdy je k dispozici primární oblast:

Diagram znázorňující, jak klienti zapisuje data do účtu úložiště v primární oblasti

Pokud se primární koncový bod z nějakého důvodu stane nedostupným, klient už nemůže zapisovat do účtu úložiště. Následující obrázek ukazuje scénář, ve kterém se primární server stal nedostupným, ale ještě nedošlo k žádnému obnovení:

Diagram znázorňující, že primární je nedostupný, takže klienti nemůžou zapisovat data.

Zákazník zahájí převzetí služeb při selhání účtu do sekundárního koncového bodu. Proces převzetí služeb při selhání aktualizuje položku DNS poskytovanou službou Azure Storage tak, aby se sekundární koncový bod pro váš účet úložiště stala novým primárním koncovým bodem, jak je znázorněno na následujícím obrázku:

Diagram znázorňující zákazníka inicializuje převzetí služeb při selhání účtu do sekundárního koncového bodu

Přístup k zápisu se obnoví pro geograficky redundantní účty po aktualizaci položky DNS a požadavky se směrují na nový primární koncový bod. Stávající koncové body služby úložiště zůstanou po převzetí služeb při selhání stejné. Při převzetí služeb při selhání se nezachovají popisovače souborů a zapůjčení, takže klienti musí sdílené složky odpojit a znovu připojit.

Důležité

Po dokončení převzetí služeb při selhání se účet úložiště nakonfiguruje tak, aby byl místně redundantní v novém primárním koncovém bodu nebo oblasti. Pokud chcete obnovit replikaci do nové sekundární lokality, znovu nakonfigurujte účet pro geografickou redundanci.

Mějte na paměti, že převod místně redundantního účtu úložiště tak, aby používal geografickou redundanci, způsobuje náklady i čas. Další informace najdete v tématu Důležité důsledky převzetí služeb při selhání účtu.

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

Upozornění

Převzetí služeb při selhání účtu obvykle zahrnuje určitou ztrátu dat. Je důležité pochopit důsledky zahájení převzetí služeb při selhání účtu.

Vzhledem k tomu, že se data zapisují asynchronně z primární oblasti do sekundární oblasti, pokud primární oblast přestane být k dispozici, nemusí se poslední zápisy ještě zkopírovat do sekundární oblasti.

Když vynutíte převzetí služeb při selhání, všechna data v primární oblasti se ztratí, protože sekundární oblast se stane novou primární oblastí. Nová primární oblast je nakonfigurovaná tak, aby byla po převzetí služeb při selhání místně redundantní.

Všechna data, která jsou už zkopírovaná do sekundárního serveru, se zachovají, když dojde k převzetí služeb při selhání. Všechna data zapsaná do primárního serveru, která nebyla také zkopírována do sekundárního serveru, se však trvale ztratí.

Kontrola vlastnosti Čas poslední synchronizace

Vlastnost LST (Last Sync Time) označuje poslední čas, kdy jsou data z primární oblasti zaručena, že byla zapsána do sekundární oblasti. Všechna data zapsaná před posledním časem synchronizace jsou k dispozici na sekundárním serveru, zatímco data zapsaná po poslední synchronizaci nemusela být zapsána do sekundárního a můžou se ztratit. Tuto vlastnost použijte v případě výpadku k odhadu množství ztráty dat, kterou může vzniknout spuštěním převzetí služeb při selhání účtu.

Aby se zajistilo, že sdílené složky jsou v konzistentním stavu, když dojde k převzetí služeb při selhání, vytvoří se snímek systému v primární oblasti každých 15 minut a replikuje se do sekundární oblasti. Když dojde k převzetí služeb při selhání sekundární oblasti, stav sdílené složky bude založen na nejnovějším snímku systému v sekundární oblasti. Pokud dojde k selhání v primární oblasti, sekundární oblast je pravděpodobně za primární oblastí, protože všechny zápisy do primární oblasti se ještě nereplikují do sekundární oblasti. Kvůli geografické prodlevě nebo jiným problémům může být nejnovější snímek systému v sekundární oblasti starší než 15 minut.

Všechny operace zápisu zapsané do primární oblasti před LST byly úspěšně replikovány do sekundární oblasti, což znamená, že jsou k dispozici ke čtení ze sekundární oblasti. Všechny operace zápisu zapsané do primární oblasti po poslední synchronizaci můžou nebo nebyly replikovány do sekundární oblasti, což znamená, že nemusí být k dispozici pro operace čtení.

Hodnotu vlastnosti Čas poslední synchronizace můžete dotazovat pomocí Azure PowerShellu, Azure CLI nebo klientské knihovny. Vlastnost Čas poslední synchronizace je hodnota data a času GMT. Další informace najdete v tématu Kontrola vlastnosti Čas poslední synchronizace pro účet úložiště.

Při navrácení služeb po obnovení do původního primárního serveru buďte opatrní.

Jak jsme už zmínili, po převzetí služeb při selhání z primární do sekundární oblasti je váš účet úložiště nakonfigurovaný tak, aby byl místně redundantní v nové primární oblasti. Účet pak můžete nakonfigurovat v nové primární oblasti pro geografickou redundanci. Když je účet nakonfigurovaný pro geografickou redundanci po převzetí služeb při selhání, nová primární oblast okamžitě začne kopírovat data do nové sekundární oblasti, která byla primární před původním převzetím služeb při selhání. Než se ale stávající data v nové primární databázi plně zkopírují do nové sekundární, může to nějakou dobu trvat.

Po změně konfigurace účtu úložiště pro geografickou redundanci je možné zahájit navrácení služeb po obnovení z nového primárního do nového sekundárního serveru. V tomto případě se původní primární oblast před převzetím služeb při selhání stane primární oblastí znovu a je nakonfigurovaná tak, aby byla buď místně redundantní, nebo zónově redundantní, v závislosti na tom, jestli původní primární konfigurace byla GRS nebo GZRS. Všechna data v primární oblasti po převzetí služeb při selhání (původní sekundární) se během navrácení služeb po obnovení ztratí. Pokud se většina dat v účtu úložiště před navrácením služeb po obnovení nezkopírovala do nové sekundární oblasti, může dojít ke ztrátě velkých objemů dat.

Pokud se chcete vyhnout závažné ztrátě dat, před navrácením služeb po obnovení zkontrolujte hodnotu vlastnosti Čas poslední synchronizace. Porovnejte čas poslední synchronizace s posledním časem, kdy byla data zapsána do nového primárního serveru, a vyhodnoťte očekávanou ztrátu dat.

Po operaci navrácení služeb po obnovení můžete novou primární oblast nakonfigurovat tak, aby byla znovu geograficky redundantní. Pokud byl pro LRS nakonfigurovaný původní primární server, můžete ho nakonfigurovat tak, aby byl GRS. Pokud byl pro ZRS nakonfigurovaný původní primární server, můžete ho nakonfigurovat na GZRS. Další možnosti najdete v tématu Změna způsobu replikace účtu úložiště.

Zahájení převzetí služeb při selhání účtu

Převzetí služeb při selhání účtu můžete zahájit z webu Azure Portal, PowerShellu, Azure CLI nebo rozhraní API poskytovatele prostředků Azure Storage. Další informace o tom, jak zahájit převzetí služeb při selhání, najdete v tématu Zahájení převzetí služeb při selhání účtu.

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

V extrémních případech, kdy dojde ke ztrátě oblasti kvůli významné havárii, může Microsoft zahájit regionální převzetí služeb při selhání. V takovém případě se nevyžaduje žádná akce na vaší straně. Dokud se nedokončí převzetí služeb při selhání spravované Microsoftem, nebudete mít k účtu úložiště přístup pro zápis.

Viz také