Tillförlitlighet i Azure Data Explorer

Azure Data Explorer är en analystjänst för att mata in, lagra och fråga 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 du aktiverar stöd för tillgänglighetszoner distribuerar tjänsten beräkningsnoder över flera tillgänglighetszoner och lagrar data med hjälp av zonredundant lagring (ZRS). 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 och dessa databaser innehåller tabeller.

Diagram som visar ett Azure Data Explorer kluster som innehåller två databasavsnitt som placeras sida vid sida. Till vänster finns en ruta med etiketten databas, och inuti den finns tre separata tabellrutor staplade lodrätt, var och en märkt tabell. Till höger finns en andra ruta märkt databas, och inuti den finns två tabellrutor staplade lodrätt, var och en också märkt tabell. Diagrammet visar en hierarki där klustret är den översta containern, varje databas är en underordnad container i klustret och tabeller är underordnade objekt i varje databas. De vänstra och högra databaserna är parallella peer-datorer i samma kluster och de kan innehålla olika antal 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. Du kan sedan köra frågor mot data 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:

• Compute layer: Azure Data Explorer är en distribuerad databehandlingsplattform och kan ha virtuella datorer med två till många noder (VM) 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 du konfigurerar klustret att använda flera tillgänglighetszoner sprids noderna mellan olika datacenter.

• Lagringslager: Azure Data Explorer använder Azure Storage som ett beständigt beständighetslager. Lagring 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 du konfigurerar klustret att använda flera tillgänglighetszoner sprids replikerna mellan olika datacenter.

Diagram som visar ett Azure Data Explorer kluster med en logisk arkitektur med två lager. I det översta lagret, märkt beräkningslager, ordnas två nodrutor sida vid sida för att visa att beräkningsarbetet fördelas över flera noder i klustret. Det nedersta lagret är märkt med lagringslager (zonredundant), med tre lagringsrutor ordnade från vänster till höger som kopia 1, kopia 2 och kopia 3. Diagrammet visar en relation i flera lager: beräkningsskiktet bearbetar inmatnings- och frågeåtgärder.

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 Azure Data Explorer REST-API:er 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 replikerar Storage ZRS synkront minst tre kopior av dina data i flera tillgänglighetszoner.

  

  Diagram som visar ett Azure Data Explorer kluster som använder flera tillgänglighetszoner. Tre lodräta kolumner är märkta tillgänglighetszon 1, tillgänglighetszon 2 och tillgänglighetszon 3. En stor ruta med etiketten Azure Data Explorer kluster omfattar alla tre kolumnerna. Boxen är indelad horisontellt i två lager. Den övre halvan utgör beräkningslagret. En nod finns i tillgänglighetszon 1 och den andra noden finns i tillgänglighetszon 2. Den nedre halvan är lagringsskiktet (zonredundant). Tre lagringsrepliker visas som kopia 1 till vänster, kopia 2 i mitten och kopia 3 till höger, där var och en motsvarar en egen tillgänglighetszon. Ett enda Azure Data Explorer kluster sträcker sig över flera zoner, med beräkningskapacitet fördelad över zoner och data som replikeras till tre zonavgränsade kopior.

• Zonal: Du kan välja en enda zon när du aktiverar tillgänglighetszoner i klustret. Microsoft placerar alla dina beräkningsnoder i den zonen. Den här konfigurationen är ett zonindelad (enzonskluster). Ett zonindelat kluster kan minska svarstiden för ovanligt svarstidskänsliga arbetsbelastningar eftersom alla beräkningsnoder körs i samma zon, men det ger inte motståndskraft mot zonavbrott.

  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.

  

  Diagram som visar ett Azure Data Explorer kluster som använder en enda tillgänglighetszon. Tre lodräta kolumner är märkta tillgänglighetszon 1, tillgänglighetszon 2 och tillgänglighetszon 3. En stor ruta med etiketten Azure Data Explorer kluster sträcker sig bara över en kolumn. Boxen är indelad horisontellt i två lager. Den övre halvan är beräkningslagret: båda noderna finns i tillgänglighetszon 1. På den nedre halvan finns lagringsskiktet (lokalt redundant), med tre lagringsrepliker i samma tillgänglighetszon. Ett enda Azure Data Explorer kluster är begränsat till en zon, med beräkning och lagring i den zonen.

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. Microsoft hanterar placering av lagringszoner och lagringsrepliker kan finnas i olika zoner från dina beräkningsnoder.

Kostnad

Att aktivera stöd för tillgänglighetszoner medför extra kostnader eftersom ZRS debiteras enligt en högre taxa än LRS. 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 situationer skapar du ett zonredundant kluster och 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 kluster utan zonindelning så att det använder 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. Funktionen är en förhandsversion. 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änglighetszoner för kluster. Använd klustrets zonstatusegenskap ( zoneStatus egenskapen i REST-API:et) för att verifiera konfigurationen av tillgänglighetszonen för ett kluster. Värdet Zonal anger att klustret använder tillgänglighetszoner, men det betyder inte att klustret körs i en enda zon.

  Använd egenskapen för att avgöra om ett kluster är zon- eller zonredundant zones . 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äkningsskikt gör sitt bästa för att fördela instanser jämnt mellan 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 Storage ZRS, vilket ger en hög nivå av datakonsekvens och minimerar risken för dataförlust vid ett zonfel.

  • Zonal: Data lagras med hjälp av Lagrings-LRS, 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.

  • Zonindelad: Du ansvarar för att identifiera fel i de tillgänglighetszoner som klustret använder. Du ansvarar också för åtgärder som du själv väljer att initiera, till exempel att växla över till ett andra kluster som du tidigare har skapat 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. Du behöver inte vidta några åtgärder.

Test för zonfel

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

• Zone-redundant: Microsoft hanterar redundans och återställning i tillgänglighetszonen fullständigt för Azure Data Explorer. Du behöver inte initiera eller bekräfta processer för tillgänglighetszonsfel.

• Zonal: Om du delvis vill simulera förlusten av alla beräkningsnoder under ett zonavbrott kan du stoppa klustret. Använd den här metoden för att validera delar av dina egna processer för detektering av zonbortfall och redundansväxling.

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 distribuerar du separata Azure Data Explorer kluster i flera regioner. Varje kluster är oberoende. 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. Välj 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 Översikt över affärskontinuitet och haveriberedskap.

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 säkerhetskopiera dina data bör du överväga följande metoder:

• Fortlöpande export exporterar regelbundet data till en extern lagringsplats och ger export exakt en gång för datatyper som stöds.

• Dataexport till molnlagring stöder manuell export av 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. Förhindra dataförlust genom att aktivera ett borttagningslås på klustret eller databasresursen.

• Oavsiktlig borttagning av tabell: Användare som har behörighet som tabelladministratör eller högre får ta bort tabeller. Om en av dessa användare av misstag tar bort en tabell kan du återställa den med kommandot undo drop table. 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 skapa tabell 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 planerat 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
• BCDR-översikt