Vytváření řešení provozní kontinuity a zotavení po havárii pomocí Azure Data Explorer

Tento článek podrobně popisuje, jak se můžete připravit na místní výpadek Azure replikací prostředků Azure Data Explorer, správy a příjmu dat v různých oblastech Azure. Je uveden příklad příjmu dat s Azure Event Hubs. Optimalizace nákladů je také popsána pro různé konfigurace architektury. Podrobnější pohled na aspekty architektury a řešení obnovení najdete v přehledu kontinuity podnikových procesů.

Příprava na oblastní výpadek Azure za účelem ochrany vašich dat

Azure Data Explorer nepodporuje automatickou ochranu před výpadkem celé oblasti Azure. K tomuto narušení může dojít během přírodní katastrofy, jako je zemětřesení. Pokud potřebujete řešení situace zotavení po havárii, proveďte následující kroky, abyste zajistili provozní kontinuitu. V těchto krocích replikujete clustery, správu a příjem dat ve dvou spárovaných oblastech Azure.

1. Vytvořte dva nebo více nezávislých clusterů ve dvou spárovaných oblastech Azure.
2. Replikujte všechny aktivity správy, jako je vytváření nových tabulek nebo správa rolí uživatelů v každém clusteru.
3. Ingestujte data do každého clusteru paralelně.

Vytvoření několika nezávislých clusterů

Vytvořte více než jeden cluster Azure Data Explorer ve více než jedné oblasti. Ujistěte se, že jsou alespoň dva z těchto clusterů vytvořené ve spárovaných oblastech Azure.

Následující obrázek ukazuje repliky, tři clustery ve třech různých oblastech.

Replikace aktivit správy

Replikujte aktivity správy, abyste měli v každé replice stejnou konfiguraci clusteru.

1. Vytvořte na každé replice totéž:

   • Databáze: K vytvoření nové databáze můžete použít Azure Portal nebo některou z našich sad SDK.
   • Tabulky
   • Mapování
   • Zásady

2. Správa ověřování a autorizace na každé replice

   

Řešení zotavení po havárii s využitím příjmu dat centra událostí

Jakmile dokončíte přípravu na výpadek v oblasti Azure kvůli ochraně vašich dat, vaše data a správa se distribuují do několika oblastí. Pokud dojde k výpadku v jedné oblasti, azure Data Explorer bude moct používat ostatní repliky.

Nastavení příjmu dat pomocí centra událostí

Pokud chcete ingestovat data z Azure Event Hubs do clusteru Azure Data Explorer jednotlivých oblastí, nejprve replikujte nastavení Azure Event Hubs v každé oblasti. Pak nakonfigurujte repliku Azure Data Explorer každé oblasti tak, aby ingestovala data z odpovídající služby Event Hubs.

Poznámka

Příjem dat přes Azure Event Hubs, IoT Hub nebo Storage je robustní. Pokud cluster není po určitou dobu dostupný, dožene ho později a vloží všechny čekající zprávy nebo objekty blob. Tento proces závisí na vytváření kontrolních bodů.

Jak je znázorněno na diagramu níže, vaše zdroje dat vytvářejí události do center událostí ve všech oblastech a každá replika Azure Data Explorer je využívá. Komponenty vizualizace dat, jako jsou Power BI, Grafana nebo webové aplikace využívající sdk, se můžou dotazovat na jednu z replik.

Optimalizace nákladů

Teď jste připraveni optimalizovat repliky pomocí některých z následujících metod:

• Vytvoření konfigurace obnovení dat na vyžádání
• Spuštění a zastavení replik
• Implementace aplikační služby s vysokou dostupností
• Optimalizace nákladů v konfiguraci aktivní-aktivní

Vytvoření konfigurace obnovení dat na vyžádání

Replikace a aktualizace nastavení Azure Data Explorer lineárně zvýší náklady s počtem replik. Pokud chcete optimalizovat náklady, můžete implementovat variantu architektury, která vyrovnává čas, převzetí služeb při selhání a náklady. V konfiguraci obnovení dat na vyžádání byla implementována optimalizace nákladů zavedením pasivních replik Azure Data Explorer. Tyto repliky se zapnou jenom v případě, že dojde k havárii v primární oblasti (například v oblasti A). Repliky v oblastech B a C nemusí být aktivní nepřetržitě, což výrazně snižuje náklady. Ve většině případů ale výkon těchto replik nebude tak dobrý jako primární cluster. Další informace najdete v tématu Konfigurace obnovení dat na vyžádání.

Na následujícím obrázku ingestuje data z centra událostí jenom jeden cluster. Primární cluster v oblasti A provádí průběžný export všech dat do účtu úložiště. Sekundární repliky mají přístup k datům pomocí externích tabulek.

Spuštění a zastavení replik

Sekundární repliky můžete spustit a zastavit pomocí jedné z následujících metod:

• Konektor Azure Data Explorer do Power Automate (Preview)

• Tlačítko Zastavit na kartě Přehled v Azure Portal. Další informace najdete v tématu Zastavení a restartování clusteru.

• Azure CLI:

az kusto cluster stop --name=<clusterName> --resource-group=<rgName> --subscription=<subscriptionId>” 

Implementace aplikační služby s vysokou dostupností

Vytvoření klienta Azure App Service BCDR

V této části se dozvíte, jak vytvořit Azure App Service, která podporuje připojení k jednomu primárnímu a několika sekundárním clusterům Azure Data Explorer. Následující obrázek znázorňuje nastavení Azure App Service.

Tip

Pokud máte více připojení mezi replikami ve stejné službě, zvýší se dostupnost. Toto nastavení není užitečné jenom v případě oblastních výpadků.

1. Použijte tento často používaný kód pro službu App Service. Pro implementaci klienta s více clustery byla vytvořena třída AdxBcdrClient . Každý dotaz, který se spustí pomocí tohoto klienta, se nejprve odešle do primárního clusteru. Pokud dojde k selhání, dotaz se odešle do sekundárních replik.

2. K měření výkonu použijte vlastní metriky Application Insights a distribuci žádostí do primárních a sekundárních clusterů.

Testování klienta Azure App Service BCDR

Spustili jsme test s použitím několika replik Azure Data Explorer. Po simulovaném výpadku primárního a sekundárního clusteru můžete vidět, že se klient BCDR služby App Service chová podle očekávání.

Clustery Azure Data Explorer se distribuují do oblastí Západní Evropa (2xD14v2 primary), Jihovýchodní Asie a USA – východ (2xD11v2).

Poznámka

Pomalejší doba odezvy je způsobená různými skladovými jednotkami a dotazy napříč planetami.

Dynamické nebo statické směrování

K dynamickému nebo statickému směrování požadavků použijte metody směrování Azure Traffic Manageru . Azure Traffic Manager je nástroj pro vyrovnávání zatížení provozu založený na DNS, který umožňuje distribuovat provoz služby App Service. Tento provoz je optimalizovaný pro služby napříč globálními oblastmi Azure a současně poskytuje vysokou dostupnost a rychlost odezvy.

Můžete také použít směrování založené na službě Azure Front Door. Porovnání těchto dvou metod najdete v tématu Vyrovnávání zatížení se sadou pro doručování aplikací Azure.

Optimalizace nákladů v konfiguraci aktivní-aktivní

Použití konfigurace aktivní-aktivní pro zotavení po havárii zvyšuje náklady lineárně. Náklady zahrnují uzly, úložiště, přirážku a zvýšené náklady na síť pro šířku pásma.

Použití optimalizovaného automatického škálování k optimalizaci nákladů

Ke konfiguraci horizontálního škálování pro sekundární clustery použijte funkci optimalizovaného automatického škálování . Měly by být dimenzované, aby zvládly zatížení příjmu dat. Jakmile primární cluster nebude dostupný, sekundární clustery budou mít větší provoz a budou se škálovat podle konfigurace.

Použití optimalizovaného automatického škálování v tomto příkladu ušetřilo přibližně 50 % nákladů v porovnání se stejným horizontálním a vertikálním škálováním na všech replikách.

Související obsah

• Přehled provozní kontinuity a zotavení po havárii