Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
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, když primární koncový bod přestane být dostupný. 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 samočinné obnovení účtu úložiště pouze tehdy, pokud je služby synchronizace úložiště také přepnuta na obnovení po 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řepnutí při selhání jenom účtu úložiště, operace synchronizace a cloud tieringu selžou, dokud služba synchronizace úložiště nebude převedena do sekundární oblasti. Pokud chcete provést převzetí služeb při selhání účtu úložiště obsahujícího sdílené složky, které jsou v Azure používány jako koncové body cloudu v Azure File Sync, přečtěte si osvědčené postupy pro obnovu Azure File Sync po havárii a obnovení serveru pro Azure File Sync.
Vztahuje se na
| Model správy | Model fakturace | Mediální vrstva | Přebytečnost | protokol SMB | NFS |
|---|---|---|---|---|---|
| Microsoft.Storage | Zajištěno v2 | SSD (Premium) | Místní (LRS) |
|
|
| Microsoft.Storage | Zajištěno v2 | SSD (Premium) | Zóna (ZRS) |
|
|
| Microsoft.Storage | Zajištěno v2 | HDD (standard) | Místní (LRS) |
|
|
| Microsoft.Storage | Zajištěno v2 | HDD (standard) | Zóna (ZRS) |
|
|
| Microsoft.Storage | Zajištěno v2 | HDD (standard) | Geografie (GRS) |
|
|
| Microsoft.Storage | Zajištěno v2 | HDD (standard) | GeoZone (GZRS) |
|
|
| Microsoft.Storage | Poskytnuto v1 | SSD (Premium) | Místní (LRS) |
|
|
| Microsoft.Storage | Poskytnuto v1 | SSD (Premium) | Zóna (ZRS) |
|
|
| Microsoft.Storage | Platba dle skutečné spotřeby | HDD (standard) | Místní (LRS) |
|
|
| Microsoft.Storage | Platba dle skutečné spotřeby | HDD (standard) | Zóna (ZRS) |
|
|
| Microsoft.Storage | Platba dle skutečné spotřeby | HDD (standard) | Geografie (GRS) |
|
|
| Microsoft.Storage | Platba dle skutečné spotřeby | HDD (standard) | GeoZone (GZRS) |
|
|
Plánované převzetí při selhání spravované zákazníkem (náhled)
Plánované převzetí služeb při selhání spravované zákazníkem je možné využít také ve více scénářích, včetně plánovaného testování zotavení po havárii, proaktivního přístupu k rozsáhlým haváriím nebo zotavení po výpadkech souvisejících s nestoragem.
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 k dispozici ve všech veřejných oblastech, které podporují GRS/GZRS s následujícími výjimkami:
- Indie – západ
- Švýcarsko – západ
Pokud chcete zjistit, jestli oblast podporuje GZRS, prohlédni si seznam oblastí Azure. Aby oblast podporovala GZRS, musí mít zóny dostupnosti a spárovanou oblast.
Metriky obnovení a náklady
Aby organizace formulovala efektivní strategii zotavení po havárii, musí pochopit:
- Kolik dat si může dovolit přijít o 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 obnovy nebo RTO)
Náklady na obnovení 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 nesmí utrpět žádnou ztrátu dat, budou platit více za DR, zatímco ti s vyššími hodnotami 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 doby do obnovení (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 sdílené složky HDD 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. Pokud primární koncový bod přestane být dostupný, můžete zahájit proces přepnutí pro váš účet úložiště. Přepnutí 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 určuje RPO. Služba Azure Files obvykle má RPO 15 minut nebo méně, i když v současné době neexistuje žádná smlouva SLA (Service Level Agreement) o tom, jak dlouho trvá replikace dat do sekundární oblasti.
Důležité
Sdílené složky SSD nepodporují GRS/GZRS. Ale můžete synchronizovat mezi dvěma souborovými úložišti 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:
- Navrhování odolných aplikací pro Azure: Přehled klíčových konceptů pro navrhování vysoce dostupných aplikací v Azure
- Kontrolní seznam odolnosti: Kontrolní seznam pro ověření, že vaše aplikace implementuje osvědčené postupy návrhu pro zajištění vysoké dostupnosti.
- Použití geografické redundance k návrhu vysoce dostupných aplikací: Pokyny k návrhu pro vytváření aplikací za účelem využití geograficky redundantního úložiště pro sdílené složky SMB.
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.
Pochopit proces obnovy účtu
Převzetí služeb při selhání účtu spravovaného zákazníkem vám umožňuje převést celý účet úložiště do sekundární oblasti, pokud se z nějakého důvodu stane primární oblast nedostupnou. 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 procesu převzetí služeb při selhání účtu doporučujeme co nejvíce pozastavit pracovní zátěž.
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í při selhání účtu
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:
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í:
Zákazník iniciuje přepnutí účtu na sekundární koncový bod. Proces převzetí služeb při selhání aktualizuje položku DNS nastavenou službou Azure Storage tak, aby se ze sekundárního koncového bodu vašeho účtu úložiště stal nový primární koncový bod, jak je znázorněno na následujícím obrázku.
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 selhání převzetí služeb se nezachovají popisovače souborů a pronájmy, 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 naleznete v dokumentaci Doba a náklady na proces failoveru.
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 havárii úč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írována do sekundárního serveru, se zachovají, když dojde k přepnutí způsobenému selháním. 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í.
Zkontrolujte vlastnost Č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ůžete utrpět při spuštění převzetí služeb v případě 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řepnutí na sekundární oblast, stav sdílení je 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 návratu k původnímu primárnímu řešení 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 návrat k novému sekundárnímu systému z nového primárního. 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 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 návratu můžete novou primární oblast nakonfigurovat, 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 Azure portálu, PowerShell, 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 části Zahájení převzetí služeb při selhání účtu.
Převzetí služeb při selhání spravované společností Microsoft
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 nebude Microsoftem spravované převzetí služeb při selhání dokončeno, nebudete mít možnost zápisu do vašeho účtu úložiště.