Sdílet prostřednictvím

Spolehlivost ve službě Azure Table Storage

Azure Table Storage je služba, která ukládá strukturovaná data NoSQL v cloudu. Poskytuje úložiště bez schématu, kde každá entita je přístupná prostřednictvím klíče a obsahuje sadu atributů. Jedna tabulka může obsahovat entity, které mají různé sady vlastností, a vlastnosti se můžou skládat z různých datových typů.

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 Table 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 můžete použít zálohy k zotavení z jiných typů problémů a zvýrazní některé klíčové informace o smlouvě SLA (Table Storage Service Level Agreement).

Poznámka:

Table Storage je součástí platformy Azure Storage. Některé z funkcí Table Storage jsou společné v mnoha službách Azure Storage. V tomto článku používáme Azure Storage nebo Storage k odkazování na tyto běžné funkce.

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

V produkčních prostředích proveďte následující akce:

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

  • Pokud potřebujete odolnost proti výpadkům oblastí a spáruje se primární oblast vašeho účtu úložiště, zvažte povolení geograficky redundantního úložiště (GRS) k asynchronní replikaci dat 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).

  • Pro úlohy v produkčním prostředí ve velkém nebo pokud máte vysoké požadavky na odolnost, zvažte použití služby Azure Cosmos DB for Table. Azure Cosmos DB for Table je kompatibilní s aplikacemi, které jsou napsané pro Table Storage. Podporuje operace čtení a zápisu s nízkou latencí ve velkém měřítku a poskytuje silnou globální distribuci napříč několika oblastmi s flexibilními modely konzistence. Poskytuje také integrované funkce zálohování a další funkce, které zlepšují odolnost a výkon vaší aplikace.

Přehled architektury spolehlivosti

Table Storage funguje jako distribuovaná databáze NoSQL v infrastruktuře platformy Azure Storage. Služba poskytuje redundanci prostřednictvím více kopií dat tabulky a 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.

Klientské knihovny a sady SDK služby Table 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), odpovědi na omezování (HTTP 429) a podmínky přetížení serveru oddílů. Když vaše aplikace dojde k těmto přechodným podmínkám, klientské knihovny automaticky opakují operace pomocí exponenciálních strategií zpoždování.

Pokud chcete efektivně spravovat přechodné chyby při použití služby Table Storage, proveďte následující akce:

  • Nakonfigurujte v klientovi Služby Table Storage odpovídající časové limity, abyste vyrovnali 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 exponenciální zpochybnění zásad opakování, zejména v případě, že u aplikace dochází k chybám vypršení časového limitu operace HTTP 503 serveru nebo vypršení časového limitu operace HTTP 500. Table Storage může omezovat požadavky, když se jednotlivé oddíly stanou horkými nebo když se blíží limity účtu úložiště.

  • Návrh logiky opakování pracující s oddíly ve vysoce škálovatelných aplikacích Logika opakování pracující s oddíly je pokročilejší přístup, který bere v úvahu dělenou architekturu ve službě Table Storage a distribuuje operace napříč několika oddíly, aby se snížila pravděpodobnost omezování na jednotlivých serverech oddílů.

Další informace o architektuře Table Storage a o tom, jak navrhovat odolné a vysoce škálované aplikace, najdete v kontrolním seznamu výkonu a škálovatelnosti pro Table 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.

Služba Table Storage je zónově redundantní, když ji nasadíte s konfigurací ZRS. Na rozdíl od místně redundantního úložiště (LRS) zaručuje ZRS synchronní replikaci dat tabulky napříč několika zónami dostupnosti. Tato konfigurace zajišťuje, aby vaše tabulky zůstaly přístupné i v případě, že nebude dostupná celá zóna dostupnosti. Všechny operace zápisu musí být potvrzeny napříč několika zónami, než služba dokončí zápis, 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 služby Table Storage v rámci daného účtu. Vzhledem k tomu, že nastavení platí pro celý účet úložiště, nemůžete nakonfigurovat jednotlivé entity pro různé úrovně redundance. 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 od vás nebo 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).

Požadavky

  • Typy účtů úložiště: Pokud chcete povolit ZRS pro Table Storage, musíte použít účet úložiště úrovně Standard pro obecné účely verze 2. Účty služby Premium Storage nepodporují Table Storage.

Náklady

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 Table Storage.

Konfigurujte podporu zón dostupnosti

  • Vytvořte zónově redundantní účet úložiště a tabulku:

    1. Vytvořte účet úložiště. Jako možnost redundance nezapomeňte vybrat geograficky redundantní úložiště SRS, GZRS nebo geograficky redundantní úložiště jen pro čtení (RA-GZRS).

    2. Vytvořte tabulku.

  • 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 Table Storage nakonfigurovaný 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 Table Storage automaticky zpracuje proces převzetí služeb při selhání tím, že reaguje následujícím chováním:

  • 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řesměrování provozu: Pokud se zóna stane nedostupnou, Azure provádí aktualizace sítí, jako je opětovné bodování DNS (Domain Name System), aby se požadavky směrovala na zbývající zóny dostupnosti, které jsou v pořádku. Služba udržuje plnou funkčnost pomocí zón, které jsou v pořádku, a nevyžaduje zásah 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.

Důležité

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řevzetí služeb při selhání spravované zákazníkem: Jste zodpovědní za zahájení obnovení v případě, že dojde k selhání jiné části vašeho řešení v primární oblasti a je nutné přepnout celé řešení na sekundární oblast. Pokud úložiště zůstává funkční v primární oblasti, použijte plánované převzetí služeb, pokud potřebujete převést své řešení do sekundární oblasti, například kvůli cvičením pro zotavení po havárii navrženým tak, aby bylo zajištěno dodržování předpisů a auditních požadavků.

  • 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í.

Požadavky

  • 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.

Úvahy

Při implementaci služby Table 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í .

Náklady

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 Table 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ě.

    Výstraha

    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

      Výstraha

      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.

    Důležité

    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.

Poznámka:

U aplikací vytvořených tak, aby používaly Table Storage, zvažte použití služby Azure Cosmos DB for Table. Azure Cosmos DB for Table podporuje pokročilé požadavky na více oblastí, včetně podpory pro nepairované oblasti. Je také navržený pro kompatibilitu s aplikacemi vytvořenými pro Table Storage.

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.

Pro Table Storage vyžaduje přístup s více účty ke správě distribuce dat, zpracování synchronizace mezi tabulkami napříč oblastmi, včetně řešení konfliktů, a implementace vlastní logiky převzetí služeb při selhání.

Zálohování a obnovení

Table Storage neposkytuje tradiční možnosti zálohování, jako je obnovení k určitému bodu v čase (PITR). Můžete ale implementovat vlastní strategie zálohování pro data tabulky.

Pokud potřebujete integrované možnosti zálohování, zvažte přechod do služby Azure Cosmos DB for Table, která poskytuje podporu pro pravidelné i průběžné zálohování. Další informace najdete v tématu Online zálohování a obnovení dat na vyžádání ve službě Azure Cosmos DB.

V případě scénářů, které vyžadují zálohování dat z Table Storage, zvažte následující přístupy:

  • Exportujte pomocí Azure Data Factory. Pomocí konektoru Azure Data Factory pro Table Storage můžete exportovat entity do jiného umístění. Každou entitu můžete například zálohovat do souboru JSON, který je uložený ve službě Azure Blob Storage.

  • Proveďte zálohování na úrovni aplikace. Implementovat vlastní logiku zálohování v aplikacích pro export důležitých entit tabulek do jiných služeb úložiště, jako je Azure SQL Database nebo Azure Cosmos DB, pro robustnější možnosti zálohování a obnovení.

Při návrhu strategií zálohování pro Table Storage zvažte dělenou povahu dat a ujistěte se, že procesy zálohování dokážou efektivně zpracovávat velké tabulky zpracováním více oddílů paralelně.

U většiny řešení byste se neměli spoléhat výhradně na zálohy. Místo toho využijte další funkce popsané v tomto průvodci k podpoře vašich požadavků na odolnost. Zálohy ale chrání před některými riziky, která jiné přístupy nechrání. Další informace najdete v tématu Co jsou redundance, replikace a zálohová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