Tillförlitlighet i Azure Data Explorer

Azure Data Explorer är en analystjänst som gör att du kan mata in, lagra och köra frågor mot stora mängder data med låg svarstid. Det används ofta för logganalys, telemetri och tidsseriearbetsbelastningar som kräver snabb frågekörning över stora datamängder.

När du använder Azure är tillförlitlighet ett delat ansvar. Microsoft tillhandahåller en rad funktioner för att stödja återhämtning och återställning. Du ansvarar för att förstå hur dessa funktioner fungerar inom alla tjänster som du använder och välja de funktioner du behöver för att uppfylla dina affärsmål och drifttidsmål.

Den här artikeln beskriver hur du gör Azure Data Explorer motståndskraftigt mot olika potentiella avbrott och problem, inklusive tillfälliga fel, fel i tillgänglighetszonen och regionomfattande fel. Den beskriver även alternativ för säkerhetskopiering och återställning och motståndskraft mot serviceunderhåll och visar viktig information om serviceavtalet (SLA) i Azure Data Explorer.

Rekommendationer för produktionsdistribution för tillförlitlighet

För produktionsarbetsbelastningar rekommenderar vi att du vidtar följande steg för att förbättra tillförlitligheten för ditt Azure Data Explorer-kluster:

• Driftsätt ett komplett kluster. Azure Data Explorer tillhandahåller kostnadsfria kluster i utvärderingssyfte. Distribuera ett fullständigt kluster för produktionsarbetsbelastningar.
• Aktivera stöd för tillgänglighetszoner. Azure Data Explorer stöder tillgänglighetszoner. När stöd för tillgänglighetszoner är aktiverat distribueras beräkningsnoder över flera tillgänglighetszoner och data lagras med zonredundant lagring. Den här konfigurationen förbättrar motståndskraften mot fel i tillgänglighetszonen.

Översikt över tillförlitlighetsarkitektur

I det här avsnittet beskrivs några av de viktiga aspekterna av hur tjänsten fungerar som är mest relevant ur ett tillförlitlighetsperspektiv. I avsnittet beskrivs den logiska arkitekturen, som innehåller några av de resurser och funktioner som du distribuerar och använder. Den diskuterar också den fysiska arkitekturen, som innehåller information om hur tjänsten fungerar under täcket.

Logisk arkitektur

Den primära resursen som du distribuerar är ett kluster som representerar den infrastruktur som du behöver för att mata in, lagra och köra frågor mot dina data. Med ett kluster skapar du databaser som i sin tur innehåller tabeller.

Kluster utför inmatning för att hämta data från andra datakällor och läsa in dem i en tabell i klustret. Data kan sedan frågas med hjälp av KQL-syntaxen (Kusto Query Language). Kluster har också en uppsättning hanteringsåtgärder som du kan utföra.

Fysisk arkitektur

Ett Azure Data Explorer-kluster har två primära lager som gäller för dess tillförlitlighetskonfiguration:

• Beräkningslager: Azure Data Explorer är en distribuerad databehandlingsplattform och kan ha två till många virtuella noddatorer (VIRTUELLA datorer) beroende på skalnings- och nodrolltyp. Noder hanterar datainmatning och frågebearbetning. Du ser eller hanterar inte de virtuella noddatorerna direkt. Plattformen hanterar automatiskt skapande av instanser, hälsoövervakning och ersättning av noder med feltillstånd. När klustret har konfigurerats för att använda tillgänglighetszoner sprids noderna mellan olika datacenter.

• Lagringslager: 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 ersätts den omedelbart utan avbrott. När klustret har konfigurerats för att använda flera tillgänglighetszoner sprids replikerna mellan olika datacenter.

Mer information finns i Så här fungerar Azure Data Explorer.

Motståndskraft mot tillfälliga fel

Tillfälliga fel är kortvariga, intermittenta fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. Tillfälliga fel korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program kan hantera tillfälliga fel, vanligtvis genom att försöka igen.

Alla molnbaserade program bör följa vägledningen för tillfälliga felhantering i Azure när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av tillfälliga fel.

Följ dessa metoder för att skapa motståndskraft mot tillfälliga fel när du använder Azure Data Explorer:

• När du använder köad inmatning förlitar du dig på det inbyggda återförsöksbeteendet.
• Använd Microsoft-tillhandahållna klientbibliotek och SDK:er, som automatiskt försöker igen när tillfälliga fel inträffar.
• Om du använder REST-API:er för Azure Data Explorer direkt kan du försöka igen med frågor och hanteringsåtgärder som misslyckas på grund av ett tillfälligt fel.

Motståndskraft mot fel i tillgänglighetszonen

Tillgänglighetszoner är fysiskt separata grupper av datacenter i en Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Azure Data Explorer har stöd för två typer av konfiguration av tillgänglighetszoner:

• Zonredundant (rekommenderas): När du aktiverar tillgänglighetszoner i klustret sprids klustrets noder över flera zoner. Microsoft hanterar distributionen av noder mellan de valda tillgänglighetszonerna och hanterar identifiering och svar på fel i tillgänglighetszonen. Ett zonredundant kluster är motståndskraftigt mot ett avbrott i tillgänglighetszonen.

  När du konfigurerar klustret till zonredundant lagras dina data med azure storage zone-redundant lagring (ZRS), som synkront replikerar minst tre kopior av data i flera tillgänglighetszoner.

  

• Zonal: Du kan välja en enda zon när du aktiverar tillgänglighetszoner i klustret. Microsoft placerar alla dina beräkningsanteckningar i den zonen. Det här är ett zonindelad kluster (en zon). Den här konfigurationen kan ibland hjälpa om du har en ovanligt svarstidskänslig arbetsbelastning, men den ger inte motståndskraft mot zonfel.

  Viktigt!

  Att fästa i en enda tillgänglighetszon rekommenderas endast när svarstiden mellan zoner är för hög för dina behov och när du har kontrollerat att svarstiden inte uppfyller dina krav. En zonresurs i sig själv ger inte resiliens mot ett avbrott i en tillgänglighetszon. För att förbättra motståndskraften för en zonindelad resurs måste du uttryckligen distribuera separata resurser till flera tillgänglighetszoner och konfigurera trafikroutning och redundans. Mer information finns i Zonresurser och zonåterhämtning.

  Zonvalet gäller endast för dina beräkningsnoder. För ett zonindelade kluster fortsätter dina lagringsdata att använda LRS och kan lagras i en annan zon än dina beräkningsnoder.

  

Om du inte aktiverar tillgänglighetszoner är klustret icke-zonalt, vilket innebär att Azure väljer tillgänglighetszonen för varje nod och dina data. Om någon tillgänglighetszon i regionen har ett avbrott kan det påverka klustrets noder, data eller båda. Vi rekommenderar inte en icke-zonbaserad konfiguration eftersom den inte ger skydd mot avbrott i tillgänglighetszonen.

Requirements

• Regionstöd: Stöd för tillgänglighetszoner är tillgängligt i Azure-regioner som stöder tillgänglighetszoner.

  Vissa typer och storlekar för beräkningsnoder är dock endast tillgängliga i specifika regioner eller specifika zoner i en region.

• Fullständiga kluster: Stöd för tillgänglighetszoner är tillgängligt med fullständiga kluster. Den är inte tillgänglig med kostnadsfria kluster.

Överväganden

Zonval: För beräkningsnoder väljer du vilka tillgänglighetszoner som ska användas. Placering av lagringszoner hanteras av Microsoft och lagringsrepliker kan placeras i olika zoner till dina beräkningsnoder.

Kostnad

Att aktivera stöd för tillgänglighetszoner medför extra kostnader för zonredundant lagring, som debiteras till en högre avgift än lokalt redundant lagring. Mer information finns i Priser för Azure Storage.

Beräkningsnoder debiteras med samma hastighet oavsett om du använder stöd för tillgänglighetszoner eller inte. Mer information finns i Priser för Azure Data Explorer.

Konfigurera stöd för tillgänglighetszoner

• Skapa ett nytt kluster med stöd för tillgänglighetszoner: Du kan aktivera stöd för tillgänglighetszoner när du skapar ett nytt Azure Data Explorer-kluster. Mer information finns i Skapa ett kluster och en databas.

  När du skapar ett tillgänglighetszonaktiverat kluster med hjälp av Azure-portalen är det automatiskt zonredundant och Microsoft väljer zonerna.

  Om du vill välja zoner själv eller skapa ett zonindelad kluster använder du en annan distributionsmetod som Azure Resource Manager-API:er eller Bicep. I de flesta fall rekommenderar vi att du skapar ett zonredundant kluster och att du använder alla zoner i regionen.

  Anmärkning

  När du väljer vilka tillgänglighetszoner som ska användas väljer du faktiskt den logiska tillgänglighetszonen. Om du distribuerar andra arbetsbelastningskomponenter i en annan Azure-prenumeration kan de använda ett annat logiskt tillgänglighetszonnummer för att få åtkomst till samma fysiska tillgänglighetszon. Mer information finns i Fysiska och logiska tillgänglighetszoner.

• Aktivera tillgänglighetszoner i ett befintligt kluster (förhandsversion): Du kan migrera ett befintligt icke-zonskluster för att använda tillgänglighetszoner. Funktionen är en förhandsversion. Mer information finns i Migrera klustret för att stödja flera tillgänglighetszoner.

• Konfigurera om tillgänglighetszoner i ett befintligt kluster (förhandsversion): Du kan ändra de zoner som används för ett kluster. Kapaciteten är i förhandsgranskning. Mer information finns i Migrera klustret för att stödja flera tillgänglighetszoner.

• Inaktivera stöd för tillgänglighetszoner i ett befintligt kluster: När ett kluster har konfigurerats med tillgänglighetszoner kan du inte ändra klustret till att inte använda tillgänglighetszoner.

• Verifiera konfigurationen av tillgänglighetszonen för kluster: Du kan använda klustrets zonstatusegenskap ( zoneStatus egenskapen i REST-API:et) för att verifiera konfigurationen av tillgänglighetszonen för ett kluster.

  Om värdet är Zonalbetyder det att klustret har konfigurerats för att använda tillgänglighetszoner. Klustret kan dock vara zonindelad eller zonredundant. För att avgöra vilken använder du egenskapen zoner . Om zonlistan har en zon i listan är klustret zonindelad (en zon). Om det finns flera zoner i listan är det zonredundant.

Kapacitetsplanering och -hantering

När en tillgänglighetszon inte är tillgänglig kan alla noder i den zonen vara tillfälligt otillgängliga, vilket minskar klustrets beräkningskapacitet tills zonen återställs.

Om klustret inte kan tolerera kapacitetsförlust bör du överväga att överetablera klustret. Med den här metoden kan lösningen tolerera viss kapacitetsförlust och fortsätta att fungera utan försämrad prestanda. Men när du överetablerar klustret kan klustret ha ett obalanserat antal noder mellan zoner.

Instansdistribution mellan zoner

Klustrets beräkningslager använder ett bästa möjliga tillvägagångssätt för att jämnt sprida instanser över de zoner som du väljer.

Beteende när alla zoner är felfria

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett kluster för stöd för tillgänglighetszoner och alla zoner är i drift.

• Åtgärd mellan zoner: Under normal drift använder Azure Data Explorer alla tillgängliga beräkningsnoder för inmatning, frågebearbetning och andra åtgärder. Arbetet distribueras mellan noder oavsett tillgänglighetszon.

• Datareplikering mellan zoner: Beteendet för datareplikering mellan zoner beror på konfigurationen av tillgänglighetszonen som klustret använder.

  • Zonredundant: Data replikeras synkront mellan tillgänglighetszoner med hjälp av Zonredundant lagring i Azure Storage. Detta ger en hög nivå av datakonsekvens och minimerar risken för dataförlust vid ett zonfel.

  • Zonal: Data lagras med hjälp av lokalt redundant lagring i Azure Storage, vilket innebär att alla tre kopiorna kan finnas i en enda tillgänglighetszon.

Beteende vid ett zonfel

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett kluster för stöd för tillgänglighetszoner och det uppstår ett avbrott i någon av zonerna.

• Identifiering och svar: Ansvaret för identifiering och svar beror på konfigurationen av tillgänglighetszonen som klustret använder.

  • Zon-redundant: Microsoft upptäcker fel i tillgänglighetszonerna och hanterar svaret för Azure Data Explorer. Du behöver inte göra något för att påbörja en zone-failover.

  • Zonal: Du ansvarar för att identifiera ett fel som påverkar en tillgänglighetszon som används av klustret. Du ansvarar också för alla svar som du bestämmer dig för att initiera, till exempel att växla till ett andra kluster som du skapade tidigare i en annan tillgänglighetszon.

• Anmälan: Microsoft meddelar dig inte automatiskt när en zon är nere. Du kan dock använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella zonfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

• Aktiva begäranden: Aktiva begäranden som förlitar sig på beräknings- eller lagringsresurser i den misslyckade zonen kan avslutas och bör försökas igen av klienten. Se till att dina program förbereds genom att följa vägledningen för tillfällig felhantering.

• Förväntad dataförlust: Den förväntade dataförlusten beror på konfigurationen av tillgänglighetszonen som klustret använder.

  • Zonredundant: Ingen dataförlust förväntas under ett avbrott i tillgänglighetszonen eftersom data replikeras synkront mellan zoner.

  • Zonal: Data är inte tillgängliga förrän zonen återställs. I det osannolika fallet att en zon som innehåller alla dina lagringsrepliker skulle förloras permanent, kan data gå förlorad permanent.

• Förväntad stilleståndstid: Den förväntade stilleståndstiden beror på konfigurationen av tillgänglighetszonen som klustret använder.

  • Zonsredundant: Ett kort tjänstavbrott kan inträffa när trafiken omdirigeras till friska tillgänglighetszoner. Se till att dina program förbereds genom att följa vägledningen för tillfällig felhantering.

  • Zonal: Klustrets beräkningsnoder är inte tillgängliga förrän tillgänglighetszonen återställs. Du kanske inte heller kan komma åt klustrets data under ett zonfel.

• Omfördelning: Beteendet för omdistribution av trafik beror på konfigurationen av tillgänglighetszonen som klustret använder.

  • Zon-redundant: Azure Data Explorer dirigerar nya begäranden till beräknings- och lagringsresurser i de återstående, fungerande zonerna.

  • Zonal: Klustret är inte tillgängligt förrän tillgänglighetszonen återställs.

Zonåterställning

När den misslyckade tillgänglighetszonen återställs återskapar Microsoft klusternoderna och lagringsreplikerna i den zonen och återställer normal trafikdistribution över alla zoner. Ingen kundåtgärd krävs.

Test för zonfel

Alternativen för testning av zonfel beror på konfigurationen av tillgänglighetszonen som klustret använder.

• Zon-redundant: Hantering av failover och återställning för tillgänglighetszoner i Azure Data Explorer sköts helt av Microsoft. Du behöver inte initiera eller validera processer för fel i tillgänglighetszoner.

• Zonal: Om du delvis vill simulera förlusten av alla beräkningsnoder under ett zonavbrott kan du stoppa klustret. Du kan använda den här metoden för att validera delar av dina egna processer för zon-neddetektering och failover.

Motståndskraft mot regionomfattande fel

Ett Azure Data Explorer-kluster distribueras till en enda Azure-region. Om den regionen blir otillgänglig är klustret och dess data inte tillgängliga.

Anpassade lösningar för flera regioner för återhämtning

För att minimera affärspåverkan av ett regionavbrott kan du distribuera separata Azure Data Explorer-kluster i flera regioner. Varje kluster är oberoende och du ansvarar för att hantera varje kluster och för att samordna datareplikering, trafikroutning och redundans mellan regioner.

Du kan välja mellan olika typer av klusterkonfigurationer för flera regioner, som var och en stöder olika nivåer av återställningstid, potentiell dataförlust, ansträngning och kostnad. Du kan välja Azure-regioner för varje kluster som stöder dina krav på svarstid och datahemvist. Mer information om klusterkonfigurationer och mönster för flera regioner som du kan följa finns i Avbrott i en Azure-region.

Säkerhetskopiering och återställning

För de flesta lösningar bör du inte enbart förlita dig på säkerhetskopior. Använd i stället de andra funktionerna som beskrivs i den här guiden för att stödja dina återhämtningskrav. Säkerhetskopior skyddar dock mot vissa risker som andra metoder inte gör. Mer information finns i Vad är redundans, replikering och säkerhetskopiering?.

Azure Data Explorer tillhandahåller inte någon inbyggd säkerhetskopierings- och återställningsfunktion. Om du behöver göra säkerhetskopior av dina data kan du överväga följande metoder:

• Kontinuerlig export, som regelbundet exporterar data till extern lagring, och stöder exakt en gång export av data som stöds.
• Dataexport till molnlagring, vilket gör att du manuellt kan exportera data till extern lagring.
• Mata in rådata till Azure Data Explorer från en uppströmskälla, till exempel en datasjö, som du kan säkerhetskopiera separat.

Motståndskraft mot oavsiktlig borttagning

Azure Data Explorer innehåller flera mekanismer som hjälper dig att skydda mot oavsiktlig borttagning av kluster, databaser, tabeller och externa tabeller:

• Oavsiktlig borttagning av kluster eller databas: Oavsiktlig borttagning av kluster eller databas är en oåterkallelig åtgärd. Du kan förhindra dataförlust genom att aktivera ett borttagningslås på klustret eller databasresursen.

• Oavsiktlig borttagning av tabell: Användare med tabelladministratörsbehörigheter eller högre får släppa tabeller. Om en av dessa användare av misstag släpper 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.

  För externa Azure Blob Storage- och Azure Data Lake-tabeller använder du funktionen för mjuk borttagning för att skydda mot oavsiktlig borttagning eller överskrivning av en blob under en användarkonfigurerad tidsperiod.

Motståndskraft mot serviceunderhåll

Azure Data Explorer tillämpar regelbundet tjänstuppdateringar och utför rutinunderhåll. Azure-plattformen hanterar dessa aktiviteter automatiskt medan den finns kvar inom de tillgänglighetsnivåer som anges i serviceavtalet. Se till att dina program är förberedda för tillfällig förlust av anslutningar under tjänstunderhåll genom att följa tillfälliga riktlinjer för felhantering.

Om du vill veta mer om kommande underhåll använder du Azure Service Health.

Serviceavtal

Serviceavtal (SLA) för Azure-tjänster beskriver den förväntade tillgängligheten för varje tjänst och de villkor som din lösning måste uppfylla för att uppnå den tillgänglighetsförväntningen. Mer information finns i Serviceavtal för onlinetjänster.

För att vara berättigad till azure datautforskarens tillgänglighets-SLA måste ditt program hantera tillfälliga fel genom att försöka utföra misslyckade begäranden igen.

Relaterat innehåll

• Tillförlitlighet i Azure
• Översikt över Azure Data Explorer
• Översikt över affärskontinuitet och haveriberedskap