Sdílet prostřednictvím

Spolehlivost ve službě Azure Queue Storage

Azure Queue Storage je služba pro ukládání a distribuci velkého počtu zpráv. Queue Storage se běžně používá k vytvoření backlogu práce pro asynchronní zpracování. Poskytuje spolehlivé doručování zpráv pro volně svázané architektury aplikací. Zpráva fronty může mít velikost až 64 kB a fronta může obsahovat miliony zpráv až do celkového limitu kapacity účtu úložiště.

Při používání Azure je spolehlivost sdílenou odpovědností. Microsoft nabízí celou řadu možností, které podporují odolnost a obnovení. Zodpovídáte za pochopení toho, jak tyto možnosti fungují ve všech službách, které používáte, a výběrem možností, které potřebujete ke splnění vašich obchodních cílů a cílů dostupnosti.

Tento článek popisuje, jak zajistit odolnost služby Queue Storage vůči nejrůznějším potenciálním výpadkům a problémům, včetně přechodných chyb, výpadků zón dostupnosti a výpadků oblastí. Popisuje také, jak se dají zálohy použít k zotavení z jiných typů problémů a zvýrazní některé klíčové informace o smlouvě o úrovni služeb (SLA) ve službě Queue Storage.

Note

Queue Storage je součástí platformy Azure Storage. Některé možnosti Queue Storage jsou běžné v mnoha službách Azure Storage.

Doporučení pro produkční nasazení pro spolehlivost

Pro produkční prostředí:

  • Povolte zónově redundantní úložiště (ZRS) pro účty úložiště, které obsahují prostředky Queue Storage. ZRS poskytuje vyšší dostupnost tím, že replikuje data synchronně napříč několika zónami dostupnosti v primární oblasti. Vyšší dostupnost pomáhá chránit účty úložiště před selháními zóny dostupnosti.

  • Pokud potřebujete odolnost proti výpadkům oblastí a primární oblast účtu úložiště je spárovaná, zvažte povolení geograficky redundantního úložiště (GRS). GRS replikuje data asynchronně do spárované oblasti. V podporovaných oblastech můžete kombinovat geografickou redundanci s redundancí zón pomocí geograficky zónově redundantního úložiště (GZRS).

U pokročilých požadavků na zasílání zpráv zvažte použití služby Azure Service Bus. Další informace o rozdílech mezi Queue Storage a Service Busem najdete v tématu Porovnání front Azure Storage a front Service Bus.

Přehled architektury spolehlivosti

Queue Storage funguje jako distribuovaná služba zasílání zpráv v infrastruktuře platformy Azure Storage. Služba poskytuje redundanci prostřednictvím několika kopií dat fronty a zpráv. Konkrétní model redundance závisí na konfiguraci vašeho účtu úložiště.

Místně redundantní úložiště (LRS) replikuje data v účtech úložiště do jedné nebo více zón dostupnosti Azure umístěných v primární oblasti podle vašeho výběru. I když není možné zvolit upřednostňovanou zónu dostupnosti, Azure může přesunout nebo rozšířit účty LRS napříč zónami, aby se zlepšilo vyrovnávání zatížení. Není zaručeno, že se vaše data budou šířit mezi zóny. Další informace o zónách dostupnosti najdete v tématu Co jsou zóny dostupnosti?.

Diagram znázorňující, jak se data replikují do zón dostupnosti pomocí LRS

Zónově redundantní úložiště (ZRS), geograficky redundantní úložiště (GRS) a geograficky zónově redundantní úložiště (GZRS) poskytují dodatečnou ochranu. Tento článek podrobně popisuje tyto možnosti.

Odolnost proti přechodným chybám

Přechodné chyby jsou krátká, přerušovaná selhání ve složkách. V distribuovaném prostředí, jako je cloud, se vyskytují často a jsou normální součástí provozu. Přechodné chyby se opravují po krátké době. Je důležité, aby vaše aplikace mohly zpracovávat přechodné chyby, obvykle opakováním ovlivněných požadavků.

Všechny aplikace hostované v cloudu by měly při komunikaci se všemi cloudovými rozhraními API, databázemi a dalšími komponentami postupovat podle pokynů pro zpracování přechodných chyb Azure. Další informace najdete v tématu Doporučení pro zpracování přechodných chyb.

Queue Storage se běžně používá v aplikacích, které jim pomáhají zvládat přechodné chyby v jiných komponentách. Pomocí asynchronního zasílání zpráv se službou, jako je Queue Storage, se aplikace můžou později zotavit z přechodných chyb opětovným zpracováním zpráv. Další informace najdete v tématu Úvod do asynchronního zasílání zpráv.

Služba Queue Storage v rámci samotné služby zpracovává přechodné chyby automaticky pomocí několika mechanismů, které poskytuje platforma Azure Storage a klientské knihovny. Služba je navržená tak, aby poskytovala odolné funkce front zpráv i během dočasných problémů s infrastrukturou.

Klientské knihovny Queue Storage zahrnují integrované zásady opakování, které automaticky zpracovávají běžné přechodné chyby, jako jsou vypršení časového limitu sítě, dočasná nedostupnost služby (HTTP 503) a odpovědi na omezování (HTTP 429). Když vaše aplikace narazí na tyto přechodné podmínky, klientské knihovny automaticky opakují operace pomocí exponenciálních strategií reoff.

Pokud chcete efektivně spravovat přechodné chyby pomocí Queue Storage, můžete provést následující akce:

  • Nakonfigurujte ve svém klientovi Queue Storage odpovídající časové limity, abyste vyvážili rychlost odezvy s odolností vůči dočasným zpomalením. Výchozí časové limity v klientských knihovnách Azure Storage jsou obvykle vhodné pro většinu scénářů.

  • Implementujte vzory jističe ve vaší aplikaci, když zpracovává zprávy z front. Vzor jističe brání kaskádovým selháním, když mají podřízené služby problémy.

  • Časové limity viditelnosti používejte správně , když vaše aplikace přijímá zprávy. Časové limity viditelnosti zajišťují, že zprávy budou k dispozici pro opakování, pokud během zpracování dojde k selhání aplikace.

Další informace o architektuře Azure Table Storage a o tom, jak navrhovat odolné a vysoce škálované aplikace, najdete v kontrolním seznamu výkonu a škálovatelnosti pro Queue Storage.

Odolnost proti chybám zóny dostupnosti

Zóny dostupnosti jsou fyzicky oddělené skupiny datacenter v rámci oblasti Azure. Když jedna zóna selže, mohou služby přejít na jednu ze zbývajících zón.

Azure Queue Storage je zónově redundantní při nasazení s konfigurací ZRS. Na rozdíl od LRS zaručuje ZRS, že Azure synchronně replikuje data fronty napříč několika zónami dostupnosti. ZRS zajišťuje, aby vaše data zůstala přístupná i v případě výpadku jedné zóny. ZRS zajišťuje, aby vaše fronty zůstaly přístupné i v případě, že nebude dostupná celá zóna dostupnosti. Všechny operace zápisu musí být před dokončením potvrzeny ve více zónách, což poskytuje záruky silné konzistence.

Redundance zón je povolená na úrovni účtu úložiště a vztahuje se na všechny prostředky Queue Storage v rámci daného účtu. Jednotlivé fronty nemůžete konfigurovat pro různé úrovně redundance. Nastavení platí pro celý účet úložiště. Když dojde k výpadku zóny dostupnosti, Azure Storage automaticky směruje požadavky do zón, které jsou v pořádku, aniž by vyžadovala zásah z vaší aplikace.

Diagram znázorňující, jak se data replikují v primární oblasti s zónově redundantním úložištěm (ZRS).

Requirements

  • Typy účtů úložiště: Pro povolení ZRS pro Queue Storage musíte použít účet úložiště úrovně Standard pro obecné účely verze 2. Účty Premium Storage nepodporují Queue Storage.

Cost

Když povolíte zónově redundantní úložiště (ZRS), bude se vám účtovat jiná sazba než místně redundantní úložiště (LRS) z důvodu dodatečné replikace a režie úložiště.

Podrobné informace o cenách najdete v tématu Ceny služby Queue Storage.

Konfigurujte podporu zón dostupnosti

  • Vytvořte zónově redundantní účet úložiště a frontu pomocí následujícího postupu.

    1. Vytvořte účet úložiště a jako možnost redundance účtu vyberte úložiště ZRS, GZRS nebo geograficky zónově redundantní úložiště s přístupem pro čtení (RA-GZRS).

    2. Vytvořte frontu.

  • Změnit typ replikace. Informace o tom, jak změnit existující účet úložiště na zónově redundantní úložiště (ZRS) a informace o možnostech konfigurace a požadavcích, najdete v tématu Změna způsobu replikace účtu úložiště.

  • Zakažte zónovou redundanci. Převeďte účty ZRS zpět na nezonální konfiguraci, jako je místně redundantní úložiště (LRS), pomocí stejného procesu změny konfigurace redundance.

Chování, když jsou všechny zóny v pořádku

Tato část popisuje, co očekávat, když je účet frontového úložiště nakonfigurován pro redundanci zón a všechny zóny dostupnosti jsou funkční.

  • Směrování provozu mezi zónami: Azure Storage s zónově redundantním úložištěm (ZRS) automaticky distribuuje požadavky mezi clustery úložiště ve více zónách dostupnosti. Distribuce provozu je pro aplikace transparentní a nevyžaduje žádnou konfiguraci na straně klienta.

  • Replikace dat mezi zónami: Všechny operace zápisu do ZRS se replikují synchronně napříč všemi zónami dostupnosti v rámci oblasti. Po nahrání nebo úpravě dat se operace nepovažuje za dokončenou, dokud se data úspěšně nereplikují napříč všemi zónami dostupnosti. Tato synchronní replikace zajišťuje silnou konzistenci a nulovou ztrátu dat během selhání zóny.

Chování při selhání zóny

Když se zóna dostupnosti stane nedostupnou, služba Queue Storage automaticky zpracuje proces převzetí služeb při selhání provedením následujících akcí.

  • Detekce a odpověď: Microsoft automaticky rozpozná selhání zóny a zahájí procesy obnovení. Pro účty zónově redundantního úložiště (ZRS) se nevyžaduje žádná akce zákazníka.

    Pokud se zóna stane nedostupnou, Azure provádí aktualizace sítí, jako je repointování DNS (Domain Name System).

  • Aktivní požadavky: Během procesu obnovení může dojít k vyřazení požadavků během letu a mělo by se to opakovat. Aplikace by měly implementovat logiku opakování pro zpracování těchto dočasných přerušení.

  • Očekávaná ztráta dat: Během selhání zóny nedojde ke ztrátě dat, protože data se před dokončením operací zápisu synchronně replikují napříč několika zónami.

  • Očekávaný výpadek: Během automatického obnovení může během automatického obnovení dojít k malému výpadku, obvykle během několika sekund, protože se provoz přesměruje do zón, které jsou v pořádku. Při návrhu aplikací pro ZRS dodržujte postupy pro zpracování přechodných chyb, včetně implementace zásad opakování s exponenciálním zpětným vypnutím.

  • Přenosy se směrují. Pokud se zóna stane nedostupnou, Azure provádí aktualizace sítí, jako je opětovné bodování DNS (Domain Name System), aby se žádosti směrly na zbývající zóny dostupnosti, které jsou v pořádku. Služba udržuje plnou funkčnost pomocí přeživších zón bez nutnosti zásahu zákazníka.

Obnovení zóny

Když se zóna dostupnosti zotaví z chyby, Azure Storage automaticky obnoví normální operace napříč všemi zónami dostupnosti. Služba automaticky zajišťuje konzistenci dat tím, že synchronizuje všechny operace, ke kterým došlo během období výpadku.

Testování poruch zón

Když používáte zónově redundantní úložiště (ZRS), Azure Storage automaticky spravuje replikaci, směrování provozu a odezvy na zónově dolů. Vzhledem k tomu, že je tato funkce plně spravována, nemusíte zahajovat ani ověřovat procesy selhání zóny dostupnosti.

Odolnost proti selháním v celé oblasti

Azure Storage, včetně Azure Blob Storage, Azure Files, Azure Table Storage a Azure Queue Storage, poskytuje celou řadu možností geografické redundance a převzetí služeb při selhání, které vyhovují různým požadavkům.

Important

Geograficky redundantní úložiště (GRS) funguje jenom v rámci spárovaných oblastí Azure. Pokud oblast vašeho účtu úložiště není spárovaná, zvažte použití vlastních řešení pro více oblastí pro zajištění odolnosti.

Geograficky redundantní úložiště pro spárované oblasti

Azure Storage poskytuje několik typů GRS ve spárovaných oblastech. Podle toho, jaký typ GRS používáte, se data v sekundární oblasti vždy replikují pomocí místně redundantního úložiště (LRS). Tento přístup poskytuje ochranu před selháním hardwaru v sekundární oblasti.

Geograficky redundantní úložiště

Typy převzetí služeb při selhání

Azure Storage podporuje tři typy převzetí služeb při selhání pro různé scénáře.

  • Neplánované převzetí služeb při selhání spravované zákazníkem: Pokud v primární oblasti dojde k selhání úložiště v celé oblasti, zodpovídáte za inicializování obnovení.

  • Plánovaný přesun spravovaný zákazníkem při selhání: Zodpovídáte za zahájení obnovy, pokud v primárním regionu došlo k selhání jiné části vašeho řešení a potřebujete přepnout celé řešení na sekundární region. Použijte plánované převzetí služeb při selhání, když úložiště zůstane funkční v primární oblasti, ale je potřeba převést celé řešení do sekundární oblasti, například při cvičeních zotavení po havárii, která zajišťují splnění požadavků na dodržování předpisů a audity.

  • Převzetí služeb při selhání spravované Microsoftem: Za výjimečných okolností může Microsoft zahájit převzetí služeb při selhání pro všechny účty geograficky redundantního úložiště (GRS) v oblasti. Převzetí služeb při selhání spravované Microsoftem je ale poslední možností a očekává se, že se provede pouze po delší době výpadku. Neměli byste spoléhat na převzetí při selhání spravované společností Microsoft.

Účty GRS můžou používat kterýkoli z těchto typů převzetí služeb při selhání. Není třeba předem nakonfigurovat účet úložiště pro použití jakéhokoli typu převzetí služeb při selhání.

Requirements

  • Typy účtů úložiště: Geo-redundantní úložiště (GRS) a převzetí a obnovení iniciované zákazníkem jsou k dispozici ve všech spárovaných oblastech Azure, které podporují účty Azure Storage verze pro obecné účely v2.

Considerations

Při implementaci služby Queue Storage pro více oblastí zvažte následující důležité faktory.

  • Latence asynchronní replikace: Replikace dat do sekundární oblasti je asynchronní, což znamená, že mezi zápisem dat do primární oblasti a dostupností dat v sekundární oblasti dochází k prodlevě. Tato prodleva může způsobit potenciální ztrátu dat, pokud dojde k selhání primární oblasti před replikací nedávných dat. Ztrátu dat měří cíl bodu obnovení (RPO). Můžete očekávat, že prodleva replikace bude kratší než 15 minut, ale tentokrát je odhad a není zaručen.

    Pokud má váš účet úložiště neplánované převzetí služeb při selhání, můžete zkontrolovat vlastnost Čas poslední synchronizace a zjistit, kolik dat může dojít ke ztrátě dat.

  • Přístup k sekundární oblasti: S konfigurací geograficky redundantního úložiště (GRS) a geograficky zónově redundantního úložiště (GZRS) není sekundární oblast přístupná pro čtení, dokud nedojde k převzetí služeb při selhání.

    Konfigurace geograficky redundantního úložiště s přístupem pro čtení (RA-GRS) a geograficky zónově redundantní úložiště s přístupem pro čtení (RA-GZRS) poskytují přístup ke čtení sekundární oblasti během normálních operací, ale kvůli latenci asynchronní replikace můžou vracet mírně zastaralá data.

  • Omezení funkcí: Některé funkce služby Azure Storage nejsou podporované nebo mají omezení, pokud používáte geograficky redundantní úložiště (GRS) nebo převzetí služeb při selhání spravované zákazníkem. Před implementací geografické redundance zkontrolujte kompatibilitu funkcí .

Cost

Konfigurace účtu Azure Storage ve více oblastech účtují dodatečné náklady na replikaci mezi oblastmi a úložiště v sekundární oblasti. Přenos dat mezi oblastmi Azure se účtuje na základě standardních sazeb šířky pásma mezi oblastmi.

Podrobné informace o cenách najdete v tématu Ceny služby Queue Storage.

Konfigurace podpory více oblastí

  • Vytvořte nový účet geograficky redundantního úložiště (GRS). Pokud chcete vytvořit účet GRS, přečtěte si téma Vytvoření účtu úložiště a výběr geograficky redundantního úložiště jen pro čtení (RA-GRS), geograficky zónově redundantního úložiště (GZRS) nebo geograficky zónově redundantního úložiště jen pro čtení (RA-GZRS) během vytváření účtu.

  • Povolte geografickou redundanci u existujícího účtu úložiště. Pokud chcete převést existující účet úložiště na geograficky redundantní úložiště (GRS), přečtěte si téma Změna způsobu replikace účtu úložiště.

    Warning

    Po změně konfigurace vašeho účtu pro geografickou redundanci může trvat značné množství času, než se stávající data v nové primární oblasti plně zkopírují do nové sekundární oblasti.

    Pokud se chcete vyhnout závažné ztrátě dat, před zahájením neplánovaného převzetí služeb při selhání zkontrolujte hodnotu vlastnosti Čas poslední synchronizace . Pokud chcete vyhodnotit potenciální ztrátu dat, porovnejte čas poslední synchronizace s časem posledního zápisu dat do nové primární oblasti.

  • Zakažte geografickou redundanci. Pomocí stejného procesu změny konfigurace redundance převeďte účty GRS zpět na konfigurace s jednou oblastí, jako je místně redundantní úložiště (LRS) nebo zónově redundantní úložiště (ZRS).

Chování, když jsou všechny oblasti v pořádku

Tato část popisuje, co očekávat, když je účet úložiště nakonfigurovaný pro geografickou redundanci a všechny oblasti jsou funkční.

  • Směrování provozu mezi oblastmi: Azure Storage používá přístup typu aktivní-pasivní, kdy se všechny operace zápisu a většina operací čtení směrují do primární oblasti.

    Pro geograficky redundantní úložiště s přístupem pro čtení (RA-GRS) a konfigurace geograficky zónově redundantního úložiště s přístupem pro čtení (RA-GZRS) můžou aplikace volitelně číst ze sekundární oblasti tak, že přistupují k sekundárnímu koncovému bodu. Tento přístup vyžaduje explicitní konfiguraci aplikace a není automatický. Kvůli prodlevě asynchronní replikace mohou být data v sekundární oblasti mírně zastaralá.

  • Replikace dat mezi oblastmi: Operace zápisu se nejprve potvrdí do primární oblasti pomocí následujících nakonfigurovaných typů redundance:

    • Místně redundantní úložiště (LRS) pro geograficky redundantní úložiště (GRS) a RA-GRS
    • Zónově redundantní úložiště (ZRS) pro geograficky zónově redundantní úložiště (GZRS) a RA-GZRS

    Po úspěšném dokončení v primární oblasti se data asynchronně replikují do sekundární oblasti, kde jsou uložená pomocí LRS.

    Asynchronní povaha replikace mezi oblastmi znamená, že mezi zápisem dat do primární oblasti a dostupností v sekundární oblasti je obvykle prodleva. Čas replikace můžete monitorovat pomocí vlastnosti Čas poslední synchronizace.

Chování při selhání oblasti

Tato část popisuje, co očekávat, když je účet úložiště nakonfigurovaný pro geografickou redundanci a v primární oblasti došlo k výpadku.

  • Převzetí služeb při selhání spravované zákazníkem (neplánované): Pokud úložiště v primární oblasti není k dispozici, použijte neplánované převzetí služeb při selhání.

    • Detekce a reakce: V nepravděpodobném případě, že váš účet úložiště není v primární oblasti dostupný, můžete zvážit zahájení zákaznicky řízeného neplánovaného převzetí služeb při selhání. Při rozhodování zvažte následující faktory:

      • Jestli azure Resource Health zobrazuje problémy s přístupem k účtu úložiště ve vaší primární oblasti

      • Jestli vám Microsoft doporučuje provést převzetí služeb při selhání do jiné oblasti

      Warning

      Neplánované převzetí služeb při selhání může vést ke ztrátě dat. Než zahájíte převzetí služeb při selhání spravované zákazníkem, rozhodněte se, jestli obnovení služby odůvodňuje riziko ztráty dat.

    • Aktivní požadavky: Během procesu převzetí služeb při selhání jsou koncové body primárního i sekundárního účtu úložiště dočasně nedostupné pro čtení i zápis. Jakékoli aktivní požadavky mohou být zrušeny a klientské aplikace musí opakovat pokus po dokončení převzetí služeb při selhání.

    • Očekávaná ztráta dat: Ztráta dat je běžná během neplánovaného převzetí služeb při selhání kvůli prodlevě asynchronní replikace, což znamená, že nedávné zápisy nemusí být replikovány. Můžete zkontrolovat vlastnost Čas poslední synchronizace a zjistit, kolik dat může být ztraceno během neplánovaného převzetí služeb při selhání. Očekávaná ztráta dat se často označuje jako cíl bodu obnovení (RPO). Obvykle můžete očekávat, že RPO bude méně než 15 minut, ale tento čas není zaručen.

    • Očekávaný výpadek: Očekávané výpadky se často označují jako plánovaná doba obnovení (RTO). Zotavení po selhání spravovaného zákazníkem se obvykle dokončí během 60 minut, v závislosti na velikosti a složitosti účtu.

    • Přesměrování provozu: Jakmile se převzetí služeb při selhání dokončí, Azure automaticky aktualizuje koncové body účtu úložiště, aby aplikace nemusely být znovu nakonfigurované. Pokud vaše aplikace uchovává záznamy DNS (Domain Name System) v mezipaměti, může být nutné vymazat mezipaměť, aby aplikace odesílala provoz do nové primární oblasti.

    • Konfigurace po převzetí služeb při selhání: Po dokončení neplánovaného převzetí služeb při selhání použije váš účet úložiště v cílové oblasti místně redundantní úroveň úložiště (LRS). Pokud ho potřebujete geograficky replikovat znovu, musíte znovu povolit geograficky redundantní úložiště (GRS) a počkat na replikaci dat do nové sekundární oblasti.

    Další informace o tom, jak iniciovat převzetí služeb při selhání spravované zákazníkem, najdete v tématu Fungování převzetí služeb při selhání spravovaného zákazníkem (neplánované) a zahájení převzetí služeb při selhání účtu úložiště.

  • Převzetí služeb při selhání spravované zákazníkem (plánované): Pokud úložiště zůstane funkční v primární oblasti, použijte plánované převzetí služeb při selhání, ale z jiného důvodu musíte převzít služby při selhání celého řešení do sekundární oblasti. Například u jiné služby Azure může docházet k problému a potřebujete přejít na použití sekundární oblasti pro celé řešení. Nebo můžete použít plánované převzetí služeb při selhání k provedení cvičení obnovy po havárii (DR) pro účely dodržování předpisů a auditu.

    • Detekce a odpověď: Zodpovídáte za rozhodnutí o převzetí provozu. Toto rozhodnutí obvykle provedete v případě, že potřebujete provést přepnutí mezi regiony, i když je váš účet úložiště v pořádku. Můžete například aktivovat převzetí služeb při selhání, pokud dojde k závažnému výpadku jiné součásti aplikace, ze které se v primární oblasti nemůžete zotavit.

    • Aktivní požadavky: Během procesu převzetí služeb při selhání jsou koncové body primárního i sekundárního účtu úložiště dočasně nedostupné pro čtení i zápis. Jakékoli aktivní požadavky mohou být zrušeny a klientské aplikace musí opakovat pokus po dokončení převzetí služeb při selhání.

    • Očekávaná ztráta dat: Neočekává se žádná ztráta dat, protože proces převzetí služeb při selhání proběhne až po synchronizaci všech dat, což vede k RPO rovný nule.

    • Očekávaný výpadek: Převzetí služeb při selhání se obvykle dokončí do 60 minut, což znamená, že očekávaná doba obnovy (RTO) je přibližně 60 minut, v závislosti na velikosti účtu a složitosti. Během procesu přepnutí jsou koncové body primárního i sekundárního účtu úložiště dočasně nedostupné pro čtení i zápis.

    • Přesměrování provozu: Jakmile se převzetí služeb při selhání dokončí, Azure automaticky aktualizuje koncové body účtu úložiště, aby aplikace nemusely být znovu nakonfigurované. Pokud vaše aplikace uchovává záznamy DNS v mezipaměti, může být nutné vymazat mezipaměť, aby se zajistilo, že aplikace odesílá provoz do nové primární oblasti.

    • Konfigurace po převzetí služeb: Po dokončení plánovaného převzetí služeb se váš účet úložiště v cílovém regionu bude dál geograficky replikovat a zůstane na úrovni GRS.

    Další informace o tom, jak iniciovat převzetí služeb při selhání spravované zákazníkem, najdete v tématu Fungování převzetí služeb při selhání spravovaného zákazníkem (plánované) a zahájení převzetí služeb při selhání účtu úložiště.

  • Převzetí služeb při selhání řízené Microsoftem: V ojedinělých případech závažné havárie, kdy Microsoft zjistí, že primární oblast je nenávratně poškozená, může být zahájeno automatické převzetí služeb sekundární oblasti při selhání. Microsoft zpracovává celý proces a nevyžaduje žádnou akci zákazníka. Doba, která uplyne před převzetím služeb při selhání, závisí na závažnosti havárie a času potřebném k vyhodnocení situace.

    Important

    Využijte možnosti převzetí služeb při poruše spravované zákazníkem k vývoji, testování a implementaci vašich plánů zotavení po havárii. Nespoléhejte na převzetí služeb při selhání spravovaném Microsoftem, které se může používat jenom za extrémních okolností. Převzetí služeb při selhání spravované Microsoftem je pravděpodobně zahájeno pro celou oblast. Nelze jej zahájit pro jednotlivé účty úložiště, předplatná nebo zákazníky. Převzetí služeb při selhání může probíhat v různých časech pro různé služby Azure. Doporučujeme použít převzetí služeb při selhání spravované zákazníkem.

Obnovení oblasti

Proces navrácení služeb po obnovení se výrazně liší ve scénářích převzetí služeb při selhání spravovaných Microsoftem a spravovanými zákazníky.

  • Převzetí služeb při selhání spravované zákazníkem (neplánované): Po neplánovaném převzetí služeb při selhání se účet úložiště nakonfiguruje s místně redundantním úložištěm (LRS). Pokud chcete provést navrácení služeb po obnovení, musíte znovu vytvořit vztah geograficky redundantního úložiště (GRS) a počkat na replikaci dat.

  • Převzetí služeb při selhání spravované zákazníkem (plánované): Po plánovaném převzetí služeb při selhání zůstane účet úložiště geograficky replikovaný. Můžete zahájit další převzetí služeb při selhání spravované zákazníkem a navrátit služby po obnovení do původní primární oblasti. Platí stejné úvahy o převzetí služeb při selhání.

  • Převzetí služeb při selhání spravované Microsoftem: Pokud Microsoft zahájí převzetí služeb při selhání, pravděpodobně dojde k významné havárii v primární oblasti a primární oblast nemusí být obnovitelná. Všechny časové osy nebo plány obnovení závisí na rozsahu regionálního úsilí o havárii a zotavení po havárii. Monitorujte komunikaci služby Azure Service Health pro podrobnosti.

Testování selhání regionů

Můžete simulovat regionální selhání a otestovat postupy zotavení po havárii.

  • Plánované testování převzetí služeb při selhání: U účtů geograficky redundantního úložiště (GRS) můžete během období údržby provádět plánované operace převzetí služeb při selhání a otestovat celý proces převzetí služeb při selhání a navrácení služeb po obnovení. Plánované převzetí služeb při selhání nevyžaduje ztrátu dat, ale zahrnuje výpadky během převzetí služeb při selhání i navrácení služeb po obnovení.

  • Testování sekundárního koncového bodu: V případě geograficky redundantního úložiště s přístupem pro čtení (RA-GRS) a konfigurací geograficky zónově redundantního úložiště s přístupem pro čtení (RA-GZRS) pravidelně testujte operace čtení na sekundárním koncovém bodu, abyste zajistili, že vaše aplikace dokáže úspěšně číst data ze sekundární oblasti.

Vlastní řešení pro více regionů pro odolnost systémů

Možnosti převzetí služeb při selhání mezi oblastmi služby Azure Storage můžou být nevhodné z následujících důvodů:

  • Váš účet úložiště je v nepárovaném regionu.

  • Vaše obchodní cíle dostupnosti nejsou splněny dobou obnovy ani ztrátou dat, které nabízejí integrované možnosti při selhání systému.

  • Musíte převzít služby při selhání do oblasti, která není párem primární oblasti.

  • Potřebujete aktivní/aktivní konfiguraci napříč oblastmi.

Tato část obsahuje základní přehled některých přístupů, které je potřeba zvážit. Komplexní přehled topologií nasazení ve více oblastech pro Azure Storage je mimo rozsah tohoto článku.

Note

Pro pokročilé požadavky na více oblastí zvažte místo toho použití služby Service Bus, která zahrnuje podporu pro neprůmyslné oblasti.

Azure Storage můžete nasadit napříč několika oblastmi pomocí samostatných účtů úložiště v každé oblasti. Tento přístup poskytuje flexibilitu při výběru oblastí, možnost používat neprůplné oblasti a podrobnější kontrolu nad načasováním replikace a konzistencí dat. Při implementaci více účtů úložiště napříč oblastmi je potřeba nakonfigurovat replikaci dat mezi oblastmi, implementovat vyrovnávání zatížení a zásady převzetí služeb při selhání a zajistit konzistenci dat napříč oblastmi.

Tento přístup vyžaduje správu distribuce zpráv, zpracování synchronizace dat mezi frontami v různých účtech úložiště a implementaci vlastní logiky převzetí služeb při selhání.

Zálohování a obnovení

Queue Storage neposkytuje tradiční možnosti zálohování, jako je obnovení k určitému bodu v čase (PITR). Důvodem je to, že fronty jsou určené pro přechodné úložiště zpráv místo dlouhodobé trvalosti dat. Zprávy se obvykle zpracovávají a odebírají z front během běžného provozu aplikace.

Pro scénáře, které vyžadují odolnost zpráv nad rámec předdefinovaných možností redundance, zvažte implementaci vlastního protokolování zpráv na úrovni aplikace nebo trvalost do trvalého úložiště dat, jako je Blob Storage nebo Azure SQL Database. Tento přístup umožňuje udržovat historii zpráv při používání služby Queue Storage pro zamýšlený účel dočasného ukládání zpráv do vyrovnávací paměti a koordinace zpracování.

Smlouva o úrovni služeb

Smlouva o úrovni služeb (SLA) pro Azure Storage popisuje očekávanou dostupnost služby a podmínky, které musí být splněny, aby bylo možné očekávat dostupnost. Smlouva SLA dostupnosti, pro kterou máte nárok, závisí na úrovni úložiště a na typu replikace, který používáte. Další informace najdete v tématu Smlouvy SLA pro online služby.

Související obsah

  • Last updated on