Přehled provozní kontinuity a zotavení po havárii
Kontinuita podnikových procesů a zotavení po havárii v Azure Data Explorer umožňují vaší firmě pokračovat v provozu i v případě přerušení. Tento článek popisuje dostupnost (v rámci oblasti) a zotavení po havárii. Podrobně popisuje nativní možnosti a aspekty architektury pro odolné nasazení Azure Data Explorer. Podrobně popisuje zotavení z lidských chyb, vysokou dostupnost a několik konfigurací zotavení po havárii. Tyto konfigurace závisí na požadavcích na odolnost, jako jsou cíl bodu obnovení (RPO) a plánovaná doba obnovení (RTO), potřebné úsilí a náklady.
Zmírnění rušivých událostí
- Chyba lidského faktoru
- Vysoká dostupnost Azure Data Explorer
- Výpadek zóny dostupnosti Azure
- Výpadek datacentra Azure
- Výpadek oblasti Azure
Chyba lidského faktoru
Lidské chyby jsou nevyhnutelné. Uživatelé můžou nechtěně odstranit cluster, databázi nebo tabulku.
Náhodné odstranění clusteru nebo databáze
Náhodné odstranění clusteru nebo databáze je nevratná akce. Jako vlastník prostředku Azure Data Explorer můžete zabránit ztrátě dat povolením funkce zámku odstranění, která je k dispozici na úrovni prostředků Azure.
Náhodné odstranění tabulky
Uživatelé s oprávněními správce tabulek nebo vyšším můžou tabulky vypustit. Pokud některý z těchto uživatelů tabulku omylem zahodí, můžete ji obnovit pomocí .undo drop table příkazu . Aby byl tento příkaz úspěšný, musíte nejprve povolit vlastnost obnovitelnosti v zásadách uchovávání informací.
Náhodné odstranění externí tabulky
Externí tabulky jsou entity schématu dotazů Kusto, které odkazují na data uložená mimo databázi. Odstranění externí tabulky odstraní pouze metadata tabulky. Můžete ho obnovit opětovným spuštěním příkazu pro vytvoření tabulky. Funkce obnovitelného odstranění slouží k ochraně před náhodným odstraněním nebo přepsáním souboru nebo objektu blob na dobu nakonfigurovanou uživatelem.
Vysoká dostupnost Azure Data Explorer
Vysoká dostupnost označuje odolnost Data Explorer Azure Data Explorer, jejích komponent a základních závislostí v rámci oblasti Azure. Tato odolnost proti chybám zabraňuje kritickým bodům způsobujícím selhání (SPOF) v implementaci. V Azure Data Explorer zahrnuje vysoká dostupnost vrstvu trvalosti, výpočetní vrstvu a konfiguraci leader-follower.
Vrstva trvalosti
Azure Data Explorer využívá Azure Storage jako svou odolnou vrstvu trvalosti. Azure Storage automaticky poskytuje odolnost proti chybám, přičemž výchozí nastavení nabízí místně redundantní úložiště (LRS) v rámci datacentra. Tři repliky jsou trvalé. Pokud dojde ke ztrátě repliky během používání, jiná se nasadí bez přerušení. Další odolnost je možná díky zónově redundantnímu úložišti (ZRS), které inteligentně rozmísťuje repliky napříč oblastmi dostupnosti Azure pro zajištění maximální odolnosti proti chybám za příplatek. Úložiště s podporou ZRS se automaticky nakonfiguruje při nasazení clusteru Azure Data Explorer do Zóny dostupnosti.
Výpočetní vrstva
Azure Data Explorer je distribuovaná výpočetní platforma, která může mít dva až mnoho uzlů v závislosti na škálování a typu role uzlu. Při zřizování vyberte zóny dostupnosti, aby se nasazení uzlu distribuuje napříč zónami, aby byla zajištěna maximální odolnost v rámci oblasti. Selhání zóny dostupnosti nebude mít za následek úplný výpadek, ale snížení výkonu až do obnovení zóny.
Konfigurace clusteru leader-follower
Azure Data Explorer poskytuje volitelnou funkci sledování vedoucího clusteru, za kterou můžou následovat další clustery sledujících, aby přístup k datům a metadatům vedoucího dodavatele byl jen pro čtení. Změny v vodicích návazcích, jako createjsou , appenda drop , se automaticky synchronizují se sledujícími. I když vedoucí pracovníci můžou zahrnovat oblasti Azure, clustery sledujících by měly být hostované ve stejných oblastech jako vedoucí. Pokud je vedoucí cluster mimo provoz nebo dojde k náhodnému vyřazení databází nebo tabulek, clustery sledujících ztratí přístup, dokud se přístup v vedoucí instanci neobnoví.
Výpadek zóny dostupnosti Azure
Zóny dostupnosti Azure jsou jedinečná fyzická umístění ve stejné oblasti Azure. Můžou chránit výpočetní prostředky a data clusteru Azure Data Explorer před částečným selháním oblasti. Selhání zóny je scénář dostupnosti, protože se jedná o uvnitř oblasti.
Připněte cluster Azure Data Explorer do stejné zóny jako ostatní připojené prostředky Azure. Další informace o povolení zón dostupnosti najdete v tématu Vytvoření clusteru.
Poznámka
Nasazení do zón dostupnosti je možné při vytváření clusteru nebo je možné ho migrovat později.
Výpadek datacentra Azure
Zóny dostupnosti Azure mají určité náklady a někteří zákazníci se rozhodnou pro nasazení bez zónové redundance. Při takovém nasazení Azure Data Explorer dojde při výpadku datacentra Azure k výpadku clusteru. Řešení výpadku datacentra Azure je proto stejné jako při výpadku oblasti Azure.
Výpadek oblasti Azure
Azure Data Explorer neposkytuje automatickou ochranu proti výpadku celé oblasti Azure. Aby se minimalizoval obchodní dopad v případě takového výpadku, několik clusterů Azure Data Explorer napříč spárovanými oblastmi Azure. Na základě vašeho cíle doby obnovení (RTO), cíle bodu obnovení (RPO) a také úsilí a nákladů existuje několik konfigurací zotavení po havárii. Optimalizace nákladů a výkonu je možná s využitím doporučení Azure Advisoru a konfigurace automatického škálování .
Konfigurace zotavení po havárii
Tato část podrobně popisuje několik konfigurací zotavení po havárii v závislosti na požadavcích na odolnost (RPO a RTO), potřebném úsilí a nákladech.
Plánovaná doba obnovení (RTO) označuje dobu zotavení po přerušení. Například rto 2 hodiny znamená, že aplikace musí být spuštěná do dvou hodin od přerušení. Cíl bodu obnovení (RPO) označuje časový interval, který může uplynout během přerušení, než množství dat ztracených během tohoto období překročí povolenou prahovou hodnotu. Pokud je například cíl bodu obnovení 24 hodin a aplikace má data začínající před 15 lety, stále jsou v rámci parametrů dohodnutého cíle bodu obnovení.
Procesy příjmu dat, zpracování a kurátorování vyžadují pečlivý návrh předem při plánování zotavení po havárii. Ingestováním se rozumí data integrovaná do Azure Data Explorer z různých zdrojů; zpracování odkazuje na transformace a podobné aktivity; kurátorováním se rozumí materializovaná zobrazení, exporty do datového jezera atd.
Níže jsou uvedené oblíbené konfigurace zotavení po havárii a každá z nich je podrobně popsaná níže.
- Konfigurace aktivní-aktivní-aktivní (always-on)
- Konfigurace aktivní-aktivní
- Konfigurace aktivního a aktivního pohotovostního režimu
- Konfigurace clusteru pro obnovení dat na vyžádání
Konfigurace aktivní-aktivní-aktivní
Tato konfigurace se také označuje jako "always-on". Pro důležitá nasazení aplikací bez tolerance k výpadkům byste měli použít několik clusterů Azure Data Explorer napříč spárovanými oblastmi Azure. Nastavte příjem dat, zpracování a kurátorování paralelně se všemi clustery. Skladová položka clusteru musí být v různých oblastech stejná. Azure zajistí, že se aktualizace nasadí a rozmístí napříč spárovanými oblastmi Azure. Výpadek oblasti Azure nezpůsobí výpadek aplikace. Může dojít k určité latenci nebo snížení výkonu.
| Konfigurace | RPO | RTO | Úsilí | Náklady |
|---|---|---|---|---|
| Active-Active-Active-n | 0 hodin | 0 hodin | Nižší | Nejvyšší |
konfigurace Active-Active
Tato konfigurace je stejná jako konfigurace aktivní-aktivní-aktivní, ale zahrnuje pouze dvě spárované oblasti Azure. Nakonfigurujte duální příjem dat, zpracování a kurátorování. Uživatelé se přesměrují do nejbližší oblasti. Skladová položka clusteru musí být stejná napříč oblastmi.
| Konfigurace | RPO | RTO | Úsilí | Náklady |
|---|---|---|---|---|
| Aktivní-aktivní | 0 hodin | 0 hodin | Nižší | Vysoká |
Active-Hot pohotovostní konfigurace
Konfigurace Active-Hot se podobá konfiguraci active-active v duálním ingestování, zpracování a kurátorování. I když je pohotovostní cluster online pro příjem dat, zpracování a kurátorování, není k dispozici k dotazování. Pohotovostní cluster nemusí být ve stejné skladové jednotce jako primární cluster. Může mít menší skladovou položku a měřítko, což může mít za následek nižší výkon. V případě havárie se uživatelé přesměrují do pohotovostního clusteru, který je možné volitelně vertikálně navýšit, aby se zvýšil výkon.
| Konfigurace | RPO | RTO | Úsilí | Náklady |
|---|---|---|---|---|
| Aktivní-aktivní pohotovostní režim | 0 hodin | Nízká | Střední | Střední |
Konfigurace obnovení dat na vyžádání
Toto řešení nabízí nejnižší odolnost (nejvyšší RPO a RTO), nejnižší náklady a nejvyšší úsilí. V této konfiguraci neexistuje žádný cluster pro obnovení dat. Nakonfigurujte průběžný export kurátorovaných dat (pokud se nevyžadují také nezpracovaná a zprostředkující data) do účtu úložiště, který je nakonfigurovaný GRS (geograficky redundantní úložiště). Cluster pro obnovení dat se vytvoří, pokud existuje scénář zotavení po havárii. V té době se použijí seznamy DTL, konfigurace, zásady a procesy. Data se ingestují z úložiště s vlastností příjmu dat kustoCreationTime za účelem překročení doby příjmu dat, která je ve výchozím nastavení systémový čas.
| Konfigurace | RPO | RTO | Úsilí | Náklady |
|---|---|---|---|---|
| Cluster pro obnovení dat na vyžádání | Nejvyšší | Nejvyšší | Nejvyšší | Nejnižší |
Souhrn možností konfigurace zotavení po havárii
| Konfigurace | Odolnost | RPO | RTO | Úsilí | Náklady |
|---|---|---|---|---|---|
| Active-Active-Active-n | Nejvyšší | 0 hodin | 0 hodin | Nižší | Nejvyšší |
| Aktivní-aktivní | Vysoká | 0 hodin | 0 hodin | Nižší | Vysoká |
| Aktivní-aktivní pohotovostní režim | Střední | 0 hodin | Nízká | Střední | Střední |
| Cluster pro obnovení dat na vyžádání | Nejnižší | Nejvyšší | Nejvyšší | Nejvyšší | Nejnižší |
Osvědčené postupy
Bez ohledu na to, jakou konfiguraci zotavení po havárii zvolíte, postupujte podle těchto osvědčených postupů:
- Všechny databázové objekty, zásady a konfigurace by měly být trvalé ve správě zdrojového kódu, aby je bylo možné uvolnit do clusteru z nástroje pro automatizaci verzí. Další informace najdete v tématu Podpora Azure DevOps pro Azure Data Explorer.
- Navrhujte, vyvíjejte a implementujte rutiny ověřování, abyste zajistili synchronizaci všech clusterů z hlediska dat. Azure Data Explorer podporuje připojení mezi clustery. Ověření může pomoct jednoduchý počet nebo řádky napříč tabulkami.
- Postupy vydávání verzí by měly zahrnovat kontroly zásad správného řízení a vyvážení, které zajišťují zrcadlení clusterů.
- Buďte plně obeznámeni s tím, co je potřeba k vytvoření clusteru od začátku.
- Vytvořte kontrolní seznam jednotek nasazení. Seznam bude jedinečný podle vašich potřeb, ale měl by obsahovat: skripty nasazení, připojení k příjmu dat, nástroje BI a další důležité konfigurace.