Översikt över affärskontinuitet och haveriberedskap

Affärskontinuitet och haveriberedskap i Azure Data Explorer gör det möjligt för ditt företag att fortsätta att fungera inför ett avbrott. Den här artikeln beskriver flera konfigurationer för haveriberedskap beroende på återställningskrav (RPO och RTO), nödvändig ansträngning och kostnad.

Mer information om tillgängliga tillförlitlighetsalternativ för Azure Data Explorer, inklusive stöd för tillgänglighetszoner, säkerhetskopiering och skydd mot vissa typer av mänskliga fel finns i Reliability i Azure Data Explorer.

Konfigurationer för haveriberedskap

Mål för återställningstid (RTO) avser den tid det tar att återställa från ett avbrott. Till exempel innebär RTO på 2 timmar att programmet måste vara igång inom två timmar efter ett avbrott. Mål för återställningspunkt avser det tidsintervall som kan passera under ett avbrott innan mängden data som förlorats under den perioden är större än det tillåtna tröskelvärdet. Om RPO till exempel är 24 timmar och ett program har data från och med 15 år sedan ligger de fortfarande inom parametrarna för det överenskomna RPO:t.

Inmatnings-, bearbetnings- och datahanteringsprocesser behöver noggrann design i förväg när man planerar för återhämtningsplanering vid katastrofer. Inmatning refererar till data som är integrerade i Azure Data Explorer från olika källor. Bearbetning refererar till transformeringar och liknande aktiviteter; kuration avser materialiserade vyer, exporter till datasjön och så vidare.

Följande är populära konfigurationer för katastrofåterställning:

• Aktiv-Aktiv-Aktiv (konfigurering som alltid är igång)
• Active-Active konfiguration
• Active-Hot väntelägeskonfiguration
• Konfiguration av dataåterställningskluster på begäran

Aktiv-aktiv-aktiv-konfiguration

Den här konfigurationen kallas även always-on. För kritiska programdistributioner utan tolerans för avbrott bör du använda flera Azure Data Explorer kluster i Azure parkopplade regioner. Konfigurera inmatning, bearbetning och curation parallellt med alla kluster. Kluster-SKU:n måste vara densamma mellan olika regioner. Azure ser till att uppdateringar distribueras och sprids över Azure parkopplade regioner. Ett Azure regionstopp orsakar inte något programstopp. Du kan uppleva viss fördröjning eller prestandaförsämring.

Active-Active-konfiguration

Den här konfigurationen är identisk med konfigurationen active-active-active, men omfattar bara två Azure parkopplade regioner. Konfigurera dubbla datainsamlingar, bearbetningar och hantering. Användare dirigeras till närmaste region. Kluster-SKU:n måste vara densamma mellan olika regioner.

Aktiv-Hett reservläge-konfiguration

Den Active-Hot-konfigurationen liknar den Active-Active-konfigurationen vid dubblerad inmatning, bearbetning och kuration. Även om väntelägesklustret är online för inmatning, bearbetning och kuration, är det inte tillgängligt för förfrågningar. Standby-klustret behöver inte finnas i samma SKU som det primära klustret. Det kan vara av en mindre SKU och skala, vilket kan resultera i att den blir mindre effektiv. I ett katastrofscenario omdirigeras användarna till väntelägesklustret, som kan skalas upp för att öka prestandan.

Konfiguration av dataåterställning på begäran

Den här lösningen erbjuder den lägsta återställningsbarheten (högsta RPO och RTO), är den lägsta i kostnad och högsta i arbete. I den här konfigurationen finns det inget dataåterställningskluster. Konfigurera kontinuerlig export av kurerade data (om inte rådata och mellanliggande data också krävs) till ett lagringskonto som är konfigurerat GRS (Geo Redundant Storage). Ett dataåterställningskluster spinns upp om det finns ett katastrofåterställningsscenario. Vid den tidpunkten tillämpas DDL:er, konfiguration, principer och processer. Data matas in från lagringen med inmatningsegenskapen kustoCreationTime för att åsidosätta inmatningstiden som är standard för systemtiden.

Sammanfattning av konfigurationsalternativ för återställning efter katastrof

Metodtips

Oavsett vilken konfiguration av haveriberedskap som väljs följer du dessa metodtips:

• Alla databasobjekt, principer och konfigurationer bör sparas i källkontrollen så att de kan släppas till klustret från versionsautomatiseringsverktyget. Mer information finns i Azure DevOps support för Azure Data Explorer.
• Utforma, utveckla och implementera valideringsrutiner för att säkerställa att alla kluster är synkroniserade ur ett dataperspektiv. Azure Data Explorer stöder cross-klusteranslutningar. Ett enkelt antal eller rader mellan tabeller kan hjälpa dig att verifiera.
• Lanseringsförfaranden bör omfatta styrningskontroller och balanser som säkerställer spegling av klustren.
• Var helt medveten om vad som krävs för att skapa ett kluster från grunden.
• Skapa en checklista med distributionsenheter. Listan är unik för dina behov, men bör innehålla: distributionsskript, inmatningsanslutningar, BI-verktyg och andra viktiga konfigurationer.

Nästa steg