Skapa lösningar för affärskontinuitet och haveriberedskap med Azure Data Explorer

Den här artikeln beskriver hur du förbereder dig för ett Azure regionalt avbrott genom att replikera dina Azure Data Explorer resurser, hantering och inmatning i olika Azure regioner. Artikeln innehåller ett exempel på datainmatning med Azure Event Hubs. I den beskrivs även kostnadsoptimering för olika arkitekturkonfigurationer. En mer ingående titt på arkitekturöverväganden och återställningslösningar finns i översikten över affärskontinuitet.

Förbereda för regionalt avbrott i Azure för att skydda dina data

Azure Data Explorer stöder inte automatiskt skydd mot avbrott i en hel Azure-region. Denna störning kan inträffa under en naturkatastrof, som en jordbävning. Om du behöver en haveriberedskapslösning följer du de här stegen för att säkerställa affärskontinuitet. I de här stegen replikerar du dina kluster, hanteringsaktiviteter och datainmatning i två Azure parkopplade regioner.

  1. Skapa två eller flera oberoende kluster i två Azure-kopplade regioner.
  2. Replikera alla hanteringsaktiviteter , till exempel att skapa nya tabeller eller hantera användarroller i varje kluster.
  3. Mata in data i varje kluster parallellt.

Skapa flera oberoende kluster

Skapa mer än ett Azure Data Explorer-kluster i mer än en region. Skapa minst två av dessa kluster i Azure parkopplade regioner.

Följande diagram visar tre replikkluster i tre olika regioner.

Diagram som visar tre oberoende Azure Data Explorer kluster i tre Azure regioner.

Duplicera hanteringsaktiviteter

Replikera hanteringsaktiviteter så att varje replik har samma klusterkonfiguration.

  1. Skapa samma resurser på varje replik:

  2. Hantera autentiseringen och auktoriseringen på varje replik.

    Diagram som visar replikerade hanteringsaktiviteter i regionala Azure Data Explorer kluster.

Haveriberedskapslösning med event hubs-inmatning

När du har slutfört Förbered för Azure regionala avbrott för att skydda dina data lagrar Azure Data Explorer dina data och din hantering i flera regioner. Om det uppstår ett avbrott i en region kan Azure Data Explorer använda de andra replikerna.

Konfigurera inmatning med hjälp av Event Hubs

Om du vill mata in data från Azure Event Hubs i varje regions Azure Data Explorer-kluster replikerar du först konfigurationen av Azure Event Hubs i varje region. Konfigurera sedan varje regions Azure Data Explorer-replik för att mata in data från motsvarande Event Hubs.

Anmärkning

Inmatning via Azure Event Hubs, IoT Hub eller Lagring är robust. Om ett kluster inte är tillgängligt för tid kommer det ikapp senare och infogar väntande meddelanden eller blobar. Den här processen förlitar sig på kontrollpunkter.

Diagram som visar Event Hubs-inmatning som konfigurerats mellan regioner för elastisk datainsamling.

Det här diagrammet visar att dina datakällor genererar händelser till Händelsehubbar i alla regioner, och varje Azure Data Explorer replik använder dessa händelser. Datavisualiseringskomponenter som Power BI, Grafana eller SDK-baserade webbappar kan köra frågor mot en replik.

Diagram som visar datakällor som skickar händelser till regionala repliker och verktyg för klientvisualisering som kör frågor mot en replik.

Optimera kostnader

Nu är du redo att optimera dina repliker med hjälp av några av följande metoder:

Skapa en konfiguration för dataåterställning på begäran

Om du replikerar och uppdaterar Azure Data Explorer konfigurationen linjärt ökar kostnaden när antalet repliker ökar. För att optimera kostnaden implementerar du en arkitekturvariant som balanserar tid, redundans och kostnad. En konfiguration för dataåterställning på begäran optimerar kostnaden med hjälp av passiva Azure Data Explorer repliker. Dessa repliker aktiveras bara om det uppstår en katastrof i den primära regionen (till exempel region A). Replikerna i regionerna B och C behöver inte vara aktiva 24/7, vilket avsevärt minskar kostnaden. Men i de flesta fall fungerar inte dessa repliker, och inte heller det primära klustret. Mer information finns i Konfiguration av dataåterställning på begäran.

I följande diagram matas endast ett kluster in data från Event Hubs. Det primära klustret i region A utför kontinuerlig dataexport av alla data till ett lagringskonto. De sekundära replikerna kommer åt data med hjälp av externa tabeller.

Diagram som visar en dataåterställningsarkitektur på begäran med ett aktivt primärt kluster och passiva repliker.

Starta och stoppa replikerna

Starta och stoppa de sekundära replikerna med någon av följande metoder:

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

Implementera en programtjänst med hög tillgänglighet

Skapa Azure App Service BCDR-klienten

Det här avsnittet visar hur du skapar en Azure App Service som stöder en anslutning till ett enda primärt och flera sekundära Azure Data Explorer-kluster. Följande bild illustrerar konfigurationen av Azure App Service.

Skapa en Azure App Service.

Tips/Råd

Om du har flera anslutningar mellan repliker i samma tjänst får du ökad tillgänglighet. Den här konfigurationen är inte bara användbar vid regionala avbrott.

  1. Använd den här exempelkoden för en apptjänst. Om du vill implementera en klient med flera kluster använder du klassen AdxBcdrClient . Varje fråga som den här klienten kör skickas först till det primära klustret. Om ett fel inträffar skickas frågan till sekundära repliker.

  2. Använd anpassade måttvärden i Application Insights för att mäta prestanda och fördelning av begäranden i primära och sekundära kluster.

Testa Azure App Service BCDR-klienten

Följande test använder flera Azure Data Explorer repliker. Efter ett simulerat avbrott i primära och sekundära kluster beter sig App Service BCDR-klienten som avsett.

Verifiera BCDR-klienten för App Service.

Azure Data Explorer-kluster är fördelade över Västeuropa (2xD14v2 primära), Sydostasien och Östra USA (2xD11v2).

Svarstid för frågor mellan planeter.

Anmärkning

Långsammare svarstider beror på olika SKU:er och frågor mellan planeter.

Utföra dynamisk eller statisk routning

Använd Azure Traffic Manager routningsmetoder för dynamisk eller statisk routning av begäranden. Azure Traffic Manager är en DNS-baserad lastbalanserare som du kan använda för att distribuera App Service-trafik. Den här trafiken är optimerad för tjänster i globala Azure-regioner, samtidigt som den ger hög tillgänglighet och svarstider.

Du kan också använda Azure Front Door-baserad routning. Jämförelse av dessa två metoder finns i Belastningsutjämning med Azures programleveranssvit.

Optimera kostnaden i en aktiv-aktiv konfiguration

Om du använder en aktiv-aktiv konfiguration för haveriberedskap ökar kostnaden linjärt. Kostnaden omfattar noder, lagring, pålägg och ökade nätverkskostnader för bandbredd.

Använd optimerad autoskalning för att optimera kostnader

Använd funktionen för optimerad autoskalning för att konfigurera horisontell skalning för de sekundära klustren. Ändra storlek på sekundära kluster för att hantera inmatningsbelastningen. När det primära klustret inte kan nås får sekundära kluster mer trafik och skalas enligt konfigurationen.

I det här exemplet sparar optimerad autoskalning ungefär 50% i kostnad jämfört med att använda samma vågräta och lodräta skala på alla repliker.