Share via

Översikt över affärskontinuitet och haveriberedskap

  • Artikel

Affärskontinuitet och haveriberedskap i Azure Data Explorer gör det möjligt för ditt företag att fortsätta arbeta vid ett avbrott. Den här artikeln beskriver tillgänglighet (inom regionen) och haveriberedskap. Den beskriver inbyggda funktioner och arkitekturöverväganden för en motståndskraftig Azure-Data Explorer distribution. Den beskriver återställning från mänskliga fel, hög tillgänglighet, följt av flera konfigurationer för haveriberedskap. Dessa konfigurationer beror på återhämtningskrav som mål för återställningspunkt (RPO) och mål för återställningstid (RTO), nödvändigt arbete och kostnad.

Minimera avbrottshändelser

Mänskligt fel

Mänskliga misstag är oundvikliga. Användare kan oavsiktligt ta bort ett kluster, en databas eller en tabell.

Oavsiktlig borttagning av kluster eller databas

Oavsiktlig borttagning av kluster eller databas är en oåterkallelig åtgärd. Som Azure-Data Explorer resursägare kan du förhindra dataförlust genom att aktivera funktionen för borttagningslås, som är tillgänglig på Azure-resursnivå.

Oavsiktlig borttagning av tabell

Användare med behörighet som tabelladministratör eller högre kan ta bort tabeller. Om någon av dessa användare av misstag tar bort en tabell kan du återställa den .undo drop table med hjälp av kommandot . För att det här kommandot ska lyckas måste du först aktivera återställningsegenskapen i kvarhållningsprincipen.

Oavsiktlig borttagning av extern tabell

Externa tabeller är Kusto-frågeschemaentiteter som refererar till data som lagras utanför databasen. Borttagning av en extern tabell tar bara bort tabellmetadata. Du kan återställa den genom att köra kommandot för att skapa tabellen igen. Använd funktionen för mjuk borttagning för att skydda mot oavsiktlig borttagning eller överskrivning av en fil/blob under en användarkonfigurerad tidsperiod.

Hög tillgänglighet för Azure Data Explorer

Hög tillgänglighet avser feltoleransen för Azure Data Explorer, dess komponenter och underliggande beroenden i en Azure-region. Den här feltoleransen undviker enskilda felpunkter (SPOF) i implementeringen. I Azure Data Explorer innehåller hög tillgänglighet beständighetslagret, beräkningsskiktet och en konfiguration med ledande följare.

Beständighetslager

Azure Data Explorer använder Azure Storage som ett beständigt beständighetslager. Azure Storage ger automatiskt feltolerans, med standardinställningen som erbjuder lokalt redundant lagring (LRS) i ett datacenter. Tre repliker sparas. Om en replik går förlorad när den används distribueras en annan utan avbrott. Ytterligare återhämtning är möjlig med zonredundant lagring (ZRS) som placerar repliker intelligent i azures regionala tillgänglighetszoner för maximal feltolerans till en extra kostnad. ZRS-aktiverad lagring konfigureras automatiskt när Azure Data Explorer-klustret distribueras till Tillgänglighetszoner.

Beräkningsskikt

Azure Data Explorer är en distribuerad databehandlingsplattform och kan ha två till många noder beroende på skalnings- och nodrolltyp. Vid etableringstillfället väljer du tillgänglighetszoner för att distribuera noddistributionen mellan zoner för maximal återhämtning inom regionen. Ett fel i tillgänglighetszonen resulterar inte i ett fullständigt avbrott, utan prestandaförsämring fram till återställningen av zonen.

Konfiguration av Leader-follower-kluster

Azure Data Explorer tillhandahåller en valfri uppföljningsfunktion för ett ledarkluster som ska följas av andra följarkluster för skrivskyddad åtkomst till ledarens data och metadata. Ändringar i ledaren, till exempel create, appendoch drop synkroniseras automatiskt till följaren. Ledarna kan sträcka sig över Azure-regioner, men de följande klustren bör finnas i samma region(er) som ledare. Om leaderklustret ligger nere eller om databaser eller tabeller tas bort av misstag förlorar de följande klustren åtkomst tills åtkomsten återställs i ledaren.

Avbrott i en Azure-tillgänglighetszon

Azure-tillgänglighetszoner är unika fysiska platser i samma Azure-region. De kan skydda ett Azure Data Explorer klusters beräkning och data från partiella regionfel. Zonfel är ett tillgänglighetsscenario eftersom det är inom regionen.

Fäst ett Azure Data Explorer-kluster i samma zon som andra anslutna Azure-resurser. Mer information om hur du aktiverar tillgänglighetszoner finns i Skapa ett kluster.

Anteckning

Distribution till tillgänglighetszoner är möjlig när du skapar ett kluster eller kan migreras senare.

Avbrott i ett Azure-datacenter

Azure-tillgänglighetszoner medför en kostnad och vissa kunder väljer att distribuera utan zonindelad redundans. Med en sådan Azure-Data Explorer distribution resulterar ett avbrott i Azure-datacentret i klusteravbrott. Hantering av ett avbrott i Ett Azure-datacenter är därför identiskt med ett avbrott i En Azure-region.

Avbrott i en Azure-region

Azure Data Explorer ger inte automatiskt skydd mot avbrott i en hel Azure-region. För att minimera påverkan på verksamheten vid ett sådant avbrott kan flera Azure-Data Explorer kluster i länkade Azure-regioner. Baserat på ditt mål för återställningstid (RTO), mål för återställningspunkt (RPO) samt överväganden för arbete och kostnader finns det flera konfigurationer för haveriberedskap. Kostnads- och prestandaoptimeringar är möjliga med Azure Advisor-rekommendationer och konfiguration av autoskalning .

Konfigurationer för haveriberedskap

Det här avsnittet beskriver flera konfigurationer för haveriberedskap beroende på återhämtningskrav (RPO och RTO), nödvändig ansträngning och kostnad.

Mål för återställningstid (RTO) avser den tid det tar att återställa efter 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 (RPO) 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 återställningspunktobjektet.

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

Följande är populära konfigurationer för haveriberedskap och var och en beskrivs i detalj nedan.

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 länkade Azure-regioner. Konfigurera inmatning, bearbetning och härdning parallellt med alla kluster. Kluster-SKU:n måste vara densamma i flera regioner. Azure ser till att uppdateringar distribueras och fördelas mellan länkade Azure-regioner. Ett avbrott i En Azure-region orsakar inte ett programstopp. Du kan uppleva viss fördröjning eller prestandaförsämring.

Active-active-active-n-konfiguration.

Konfiguration RPO RTO Projektet Kostnad
Aktiv-aktiv-aktiv-n 0 timmar 0 timmar Lägre Högsta

Active-Active konfiguration

Den här konfigurationen är identisk med konfigurationen aktiv-aktiv-aktiv, men omfattar bara två länkade Azure-regioner. Konfigurera dubbel inmatning, bearbetning och härdning. Användarna dirigeras till närmaste region. Kluster-SKU:n måste vara densamma i flera regioner.

Aktiv-aktiv-konfiguration.

Konfiguration RPO RTO Projektet Kostnad
Aktiv-aktiv 0 timmar 0 timmar Lägre Högt

konfiguration av Active-Hot vänteläge

Den Active-Hot konfigurationen liknar active-active-konfigurationen vid dubbel inmatning, bearbetning och härdning. Väntelägesklustret är online för inmatning, process och kuration, men det är inte tillgängligt för frågor. 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 leda till att den blir mindre högpresterande. I ett katastrofscenario omdirigeras användarna till väntelägesklustret, som kan skalas upp för att öka prestandan.

Aktiv-frekvent väntelägeskonfiguration.

Konfiguration RPO RTO Projektet Kostnad
Aktiv-het vänteläge 0 timmar Låg Medel Medel

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

Den här lösningen erbjuder minst återhämtning (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 granskade data (såvida inte rådata och mellanliggande data också krävs) till ett lagringskonto som har konfigurerats för GRS (geo-redundant lagring). Ett dataåterställningskluster spunnits upp om det finns ett haveriberedskapsscenario. Vid den tidpunkten tillämpas DDL:er, konfiguration, principer och processer. Data matas in från lagring med inmatningsegenskapen kustoCreationTime för att överdriva den inmatningstid som är standard för systemtid.

Konfiguration av dataåterställningskluster på begäran.

Konfiguration RPO RTO Projektet Kostnad
Dataåterställningskluster på begäran Högsta Högsta Högsta Lägsta

Sammanfattning av konfigurationsalternativ för haveriberedskap

Konfiguration Elasticitet RPO RTO Projektet Kostnad
Aktiv-aktiv-aktiv-n Högsta 0 timmar 0 timmar Lägre Högsta
Aktiv-aktiv Högt 0 timmar 0 timmar Lägre Högt
Aktiv-het vänteläge Medel 0 timmar Låg Medel Medel
Dataåterställningskluster på begäran Lägsta Högsta Högsta Högsta Lägsta

Bästa praxis

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

  • Alla databasobjekt, principer och konfigurationer ska bevaras i källkontrollen så att de kan släppas till klustret från versionsautomatiseringsverktyget. Mer information finns i Azure DevOps-stöd 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 korsklusteranslutningar. Ett enkelt antal eller rader mellan tabeller kan hjälpa dig att verifiera.
  • Lanseringsprocedurerna bör omfatta styrningskontroller och saldon 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

Skapa lösningar för affärskontinuitet och haveriberedskap