Betrouwbaarheid in Azure Data Explorer

Azure Data Explorer is een analyseservice voor het opnemen, opslaan en opvragen van grote hoeveelheden gegevens met lage latentie. Het wordt vaak gebruikt voor log analytics-, telemetrie- en tijdreeksworkloads waarvoor snelle query's moeten worden uitgevoerd op grote gegevenssets.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u Azure Data Explorer bestand maakt tegen verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, fouten in de beschikbaarheidszone en regiobrede fouten. Ook worden back-up- en herstelopties en tolerantie voor serviceonderhoud beschreven en worden belangrijke informatie over de Service Level Agreement (SLA) van Azure Data Explorer gemarkeerd.

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Voor productieworkloads raden we u aan de volgende stappen uit te voeren om de betrouwbaarheid van uw Azure Data Explorer-cluster te verbeteren:

Overzicht van betrouwbaarheidsarchitectuur

In deze sectie worden enkele belangrijke aspecten beschreven van de werking van de service die het meest relevant is vanuit het perspectief van betrouwbaarheid. In de sectie wordt de logische architectuur geïntroduceerd, die enkele van de resources en functies bevat die u implementeert en gebruikt. Ook wordt de fysieke architectuur besproken, die details biedt over hoe de service achter de schermen werkt.

Logische architectuur

De primaire resource die u implementeert, is een cluster dat de infrastructuur vertegenwoordigt die u nodig hebt om uw gegevens op te nemen, op te slaan en er query's op uit te voeren. Met een cluster maakt u databases en deze databases bevatten tabellen.

Clusters voeren opname uit om gegevens op te halen uit andere gegevensbronnen en deze in een tabel in het cluster te laden. U kunt vervolgens query's uitvoeren op gegevens met behulp van de KQL-syntaxis (Kusto Query Language). Clusters hebben ook een set beheerbewerkingen die u kunt uitvoeren.

Fysieke architectuur

Een Azure Data Explorer-cluster heeft twee primaire lagen die van toepassing zijn op de betrouwbaarheidsconfiguratie:

• Rekenlaag: Azure Data Explorer is een gedistribueerd computerplatform en kan, afhankelijk van de schaal en het type knooppuntrol, uit twee of meer virtuele machines (VM's) met knooppunten bestaan. Knooppunten verwerken gegevensopname en het verwerken van query's. U ziet of beheert de knooppunt-VM's niet rechtstreeks. Het platform beheert automatisch het maken van exemplaren, statuscontrole en vervanging van beschadigde knooppunten. Wanneer u uw cluster configureert voor het gebruik van meerdere beschikbaarheidszones, worden de knooppunten verdeeld over verschillende datacenters.

• Opslaglaag: Azure Data Explorer maakt gebruik van Azure Storage als duurzame persistentielaag. Opslag biedt automatisch fouttolerantie, met de standaardinstelling die lokaal redundante opslag (LRS) binnen een datacenter biedt. Er worden drie replica's bewaard. Als een replica verloren gaat tijdens het gebruik, wordt er zonder onderbreking een andere geïmplementeerd. Wanneer u uw cluster configureert voor het gebruik van meerdere beschikbaarheidszones, worden de replica's verspreid over verschillende datacenters.

Zie Hoe Azure Data Explorer werkt voor meer informatie.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle cloudtoepassingen moeten de Azure richtlijnen voor tijdelijke foutafhandeling volgen wanneer ze communiceren met api's, databases en andere onderdelen die in de cloud worden gehost. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

Volg deze procedures om tolerantie te bouwen voor tijdelijke fouten wanneer u Azure Data Explorer gebruikt:

• Wanneer u opname in de wachtrij gebruikt, vertrouwt u op het ingebouwde gedrag voor opnieuw proberen.

• Gebruik door Microsoft geleverde clientbibliotheken en SDK's, die automatisch opnieuw proberen wanneer tijdelijke fouten optreden.

• Als u Azure Data Explorer REST API's rechtstreeks gebruikt, probeert u query's en beheerbewerkingen die mislukken door een tijdelijke fout opnieuw uit te voeren.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Azure Data Explorer ondersteunt twee typen configuratie van beschikbaarheidszones:

• Zone-redundant (aanbevolen): Wanneer u beschikbaarheidszones op uw cluster inschakelt, worden de knooppunten van uw cluster verspreid over meerdere zones. Microsoft beheert de distributie van knooppunten in de geselecteerde beschikbaarheidszones en verwerkt detectie en reactie op fouten in de beschikbaarheidszone. Een zone-redundant cluster is tolerant voor een storing in de beschikbaarheidszone.

  Wanneer u uw cluster configureert als zone-redundant, repliceert Storage ZRS synchroon ten minste drie kopieën van uw gegevens in meerdere beschikbaarheidszones.

  

  Diagram met een Azure Data Explorer cluster dat gebruikmaakt van meerdere beschikbaarheidszones. Drie verticale kolommen hebben het label beschikbaarheidszone 1, beschikbaarheidszone 2 en beschikbaarheidszone 3. Een groot vak met het label Azure Data Explorer cluster omvat alle drie de kolommen. De doos is horizontaal verdeeld in twee lagen. De bovenste helft is de rekenlaag. Het ene knooppunt bevindt zich in beschikbaarheidszone 1 en het andere knooppunt bevindt zich in de beschikbaarheidszone 2. De onderste helft is de opslaglaag (zone-redundant). Drie opslagreplica’s worden weergegeven als kopie 1 aan de linkerkant, kopie 2 in het midden en kopie 3 aan de rechterkant, elk gekoppeld aan een andere beschikbaarheidszone. Eén Azure Data Explorer cluster strekt zich uit over meerdere zones, met rekencapaciteit verspreid over zones en gegevens die worden gerepliceerd in drie door zones gescheiden kopieën.

• Zonal: U kunt desgewenst één zone selecteren wanneer u beschikbaarheidszones in uw cluster inschakelt. Microsoft plaatst al uw rekenknooppunten in die zone. Deze configuratie is een zonegebonden cluster (één zone). Een zonegebonden cluster kan de latentie voor ongebruikelijk latentiegevoelige workloads verminderen omdat alle rekenknooppunten in dezelfde zone worden uitgevoerd, maar het biedt geen tolerantie voor zonestoringen.

  Belangrijk

  Vastmaken aan één beschikbaarheidszone wordt alleen aanbevolen wanneer latentie tussen zones te hoog is voor uw behoeften en nadat u hebt gecontroleerd of de latentie niet aan uw vereisten voldoet. Een zonegebonden resource biedt zelf geen tolerantie voor een storing in de beschikbaarheidszone. Om de tolerantie van een zonegebonden resource te verbeteren, moet u expliciet afzonderlijke resources implementeren in meerdere beschikbaarheidszones en verkeersroutering en failover configureren. Zie Zoneresources en zonetolerantie voor meer informatie.

  Uw zoneselectie is alleen van toepassing op uw rekenknooppunten. Voor een zonegebonden cluster blijven uw opslaggegevens LRS gebruiken en worden ze mogelijk opgeslagen in een andere zone dan uw rekenknooppunten.

  

  Diagram met een Azure Data Explorer cluster dat gebruikmaakt van één beschikbaarheidszone. Drie verticale kolommen hebben het label beschikbaarheidszone 1, beschikbaarheidszone 2 en beschikbaarheidszone 3. Een groot vak met het label Azure Data Explorer cluster bestaat uit slechts één kolom. De doos is horizontaal verdeeld in twee lagen. De bovenste helft is de rekenlaag: beide knooppunten bevinden zich in beschikbaarheidszone 1. In de onderste helft bevindt zich de opslaglaag (lokaal redundant), met drie opslagreplica’s in dezelfde beschikbaarheidszone. Eén Azure Data Explorer cluster is beperkt tot één zone, met rekenkracht en opslag in die zone.

Als u geen beschikbaarheidszones inschakelt, is het cluster niet-zonegebonden, wat betekent dat Azure de beschikbaarheidszone voor elk knooppunt en uw gegevens selecteert. Als een beschikbaarheidszone in de regio een storing heeft, kan dit van invloed zijn op de knooppunten, gegevens of beide van uw cluster. We raden een niet-zonegebonden configuratie niet aan, omdat deze geen bescherming biedt tegen storingen in de beschikbaarheidszone.

Requirements

• Regioondersteuning: Ondersteuning voor beschikbaarheidszones is beschikbaar in Azure-regio's die beschikbaarheidszones ondersteunen.

  Sommige typen rekenknooppunten en -grootten zijn echter alleen beschikbaar in specifieke regio's of specifieke zones binnen een regio.

• Volledige clusters: Ondersteuning voor beschikbaarheidszones is beschikbaar voor volledige clusters. Het is niet beschikbaar met gratis clusters.

Overwegingen

Zoneselectie: Voor rekenknooppunten kiest u welke beschikbaarheidszones u wilt gebruiken. Microsoft de plaatsing van de opslagzone beheert, en opslagreplica's bevinden zich mogelijk in verschillende zones van uw rekenknooppunten.

Cost

Voor het inschakelen van ondersteuning voor beschikbaarheidszones worden extra kosten in rekening gebracht voor ZRS, die tegen een hoger tarief worden gefactureerd dan LRS. Zie prijzen voor Azure Storage voor meer informatie.

Rekenknooppunten worden met hetzelfde tarief in rekening gebracht, ongeacht of u ondersteuning voor beschikbaarheidszones gebruikt of niet. Zie prijzen voor Azure Data Explorer voor meer informatie.

Ondersteuning voor beschikbaarheidszones configureren

• Maak een nieuw cluster met ondersteuning voor beschikbaarheidszones. U kunt ondersteuning voor beschikbaarheidszones inschakelen wanneer u een nieuw Azure Data Explorer-cluster maakt. Zie Een cluster en database maken voor meer informatie.

  Wanneer u met behulp van de Azure-portal een cluster maakt waarvoor beschikbaarheidszones zijn ingeschakeld, is dit automatisch zone-redundant en selecteert Microsoft de zones.

  Als u zelf zones wilt selecteren of een zonegebonden cluster wilt maken, gebruikt u een andere implementatiebenadering, zoals Azure Resource Manager-API's of Bicep. Maak in de meeste gevallen een zone-redundant cluster en gebruik alle zones in de regio.

  Opmerking

  Wanneer u selecteert welke beschikbaarheidszones u wilt gebruiken, selecteert u daadwerkelijk de logische beschikbaarheidszone. Als u andere workloadonderdelen in een ander Azure-abonnement implementeert, kunnen ze een ander nummer voor een logische beschikbaarheidszone gebruiken om toegang te krijgen tot dezelfde fysieke beschikbaarheidszone. Zie fysieke en logische beschikbaarheidszones voor meer informatie.

• Beschikbaarheidszones inschakelen op een bestaand cluster (preview). U kunt een bestaand niet-zonegebonden cluster migreren om beschikbaarheidszones te gebruiken. Deze functionaliteit is momenteel beschikbaar als preview. Zie Uw cluster migreren voor ondersteuning van meerdere beschikbaarheidszones voor meer informatie.

• Configureer beschikbaarheidszones opnieuw op een bestaand cluster (preview). U kunt de zones wijzigen die voor een cluster worden gebruikt. Deze functionaliteit is momenteel beschikbaar als preview. Zie Uw cluster migreren voor ondersteuning van meerdere beschikbaarheidszones voor meer informatie.

• Schakel ondersteuning voor beschikbaarheidszones uit op een bestaand cluster. Nadat een cluster is geconfigureerd met beschikbaarheidszones, kunt u het cluster niet wijzigen om geen beschikbaarheidszones te gebruiken.

• Controleer de configuratie van de beschikbaarheidszone voor clusters. Gebruik de zonestatuseigenschap van het cluster (de zoneStatus eigenschap in de REST API) om de configuratie van de beschikbaarheidszone van een cluster te controleren. Een waarde van Zonal geeft aan dat het cluster beschikbaarheidszones gebruikt, maar dit betekent niet dat het cluster in één zone wordt uitgevoerd.

  Gebruik de eigenschap zones om te bepalen of een cluster zonaal of zone-redundant is. Als de lijst met zones één zone bevat, is het cluster zonegebonden (één zone). Als er meerdere zones worden vermeld, is het zone-redundant.

Capaciteitsplanning en -beheer

Wanneer een beschikbaarheidszone niet beschikbaar is, zijn knooppunten in die zone mogelijk tijdelijk niet beschikbaar, waardoor de rekencapaciteit van uw cluster wordt verminderd totdat de zone wordt hersteld.

Als uw cluster het verlies van capaciteit niet tolereert, kunt u overwegen om uw cluster te overprovisioneren . Met deze aanpak kan de oplossing enige capaciteitsverlies tolereren en blijven werken zonder verslechterde prestaties. Wanneer u het cluster echter overprovisioneert, heeft uw cluster mogelijk een niet-verdeeld aantal knooppunten tussen zones.

Exemplaardistributie tussen zones

De rekenlaag van het cluster maakt gebruik van een best effort-benadering om instanties gelijkmatig te verdelen over de zones die u selecteert.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een cluster configureert voor ondersteuning voor beschikbaarheidszones en alle zones operationeel zijn.

• Bewerking tussen zones: Tijdens de normale bewerking gebruikt Azure Data Explorer alle beschikbare rekenknooppunten voor opname, queryverwerking en andere bewerkingen. Werk wordt verdeeld over knooppunten, ongeacht hun beschikbaarheidszone.

• Replicatie van gegevens in meerdere zones: Het replicatiegedrag van gegevens in meerdere zones is afhankelijk van de configuratie van de beschikbaarheidszone die door uw cluster wordt gebruikt.

  • Zone-redundant: Gegevens worden synchroon gerepliceerd in beschikbaarheidszones met behulp van Storage ZRS, wat een hoog gegevensconsistentieniveau biedt en het risico op gegevensverlies tijdens een zonefout minimaliseert.

  • Zonal: Gegevens worden opgeslagen met behulp van Storage LRS, wat betekent dat alle drie de kopieën zich in één beschikbaarheidszone kunnen bevinden.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een cluster configureert voor ondersteuning voor beschikbaarheidszones en er een storing optreedt in een van de zones.

• Detectie en reactie: De verantwoordelijkheid voor detectie en reactie is afhankelijk van de configuratie van de beschikbaarheidszone die door uw cluster wordt gebruikt.

  • Zone-redundant: Microsoft detecteert fouten in de beschikbaarheidszone en beheert het antwoord voor Azure Data Explorer. U hoeft niets te doen om een zonefailover te starten.

  • Zonal: U bent verantwoordelijk voor het detecteren van fouten in de beschikbaarheidszones die door uw cluster worden gebruikt. U bent ook verantwoordelijk voor reacties die u wilt initiëren, zoals overschakelen naar een tweede cluster dat u eerder in een andere beschikbaarheidszone hebt gemaakt.

• Bekendmaking: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Actieve aanvragen die afhankelijk zijn van reken- of opslagresources in de mislukte zone, kunnen worden beëindigd en moeten opnieuw worden geprobeerd door de client. Zorg ervoor dat uw toepassingen zijn voorbereid door de richtlijnen voor het afhandelen van tijdelijke fouten te volgen.

• Verwachte gegevensverlies: Het verwachte gegevensverlies is afhankelijk van de configuratie van de beschikbaarheidszone die door uw cluster wordt gebruikt.

  • Zone-redundant: Er wordt geen gegevensverlies verwacht tijdens een storing in de beschikbaarheidszone, omdat gegevens synchroon worden gerepliceerd tussen zones.

  • Zonal: Gegevens zijn niet beschikbaar totdat de zone wordt hersteld. In het onwaarschijnlijke geval van een permanent verlies van een zone die al uw opslagreplica's bevat, gaan de gegevens mogelijk permanent verloren.

• Verwachte downtime: De verwachte downtime is afhankelijk van de configuratie van de beschikbaarheidszone die door uw cluster wordt gebruikt.

  • Zone-redundant: Er kan een korte serviceonderbreking optreden terwijl verkeer wordt omgeleid naar gezonde beschikbaarheidszones. Zorg ervoor dat uw toepassingen zijn voorbereid door de richtlijnen voor het afhandelen van tijdelijke fouten te volgen.

  • Zonal: De rekenknooppunten van uw cluster zijn niet beschikbaar totdat de beschikbaarheidszone wordt hersteld. Mogelijk hebt u tijdens een zonefout geen toegang tot de gegevens van uw cluster.

• Herverdeling: Het gedrag voor het opnieuw omleiden van verkeer is afhankelijk van de configuratie van de beschikbaarheidszone die door uw cluster wordt gebruikt.

  • Zone-redundant: Azure Data Explorer stuurt nieuwe aanvragen naar reken- en opslagresources in de resterende zones die in orde zijn.

  • Zonal: Uw cluster is niet beschikbaar totdat de beschikbaarheidszone wordt hersteld.

Zoneherstel

Wanneer de mislukte beschikbaarheidszone wordt hersteld, maakt Microsoft de clusterknooppunten en opslagreplica's in die zone opnieuw en herstelt het normale verkeer over alle zones. U hoeft geen actie te ondernemen.

Testen op zonefouten

De opties voor het testen van zonefouten zijn afhankelijk van de configuratie van de beschikbaarheidszone die door uw cluster wordt gebruikt.

• Zone-redundant: Microsoft beheert failover van beschikbaarheidszones en herstel voor Azure Data Explorer volledig. U hoeft geen processen voor fouten in de beschikbaarheidszone te initiëren of valideren.

• Zonal: Als u gedeeltelijk het verlies van alle rekenknooppunten tijdens een zonestoring wilt simuleren, kunt u het cluster stoppen. Gebruik deze methode om onderdelen van uw eigen zone-down detectie- en failoverprocessen te valideren.

Tolerantie voor storingen in de hele regio

Een Azure Data Explorer-cluster wordt geïmplementeerd in één Azure-regio. Als deze regio niet meer beschikbaar is, zijn het cluster en de bijbehorende gegevens niet beschikbaar.

Aangepaste multiregionale oplossingen voor veerkracht

Als u de bedrijfsimpact van een regiostoring wilt minimaliseren, implementeert u afzonderlijke Azure Data Explorer clusters in meerdere regio's. Elk cluster is onafhankelijk. U bent verantwoordelijk voor het beheren van elk cluster en voor het coördineren van gegevensreplicatie, verkeersroutering en failover tussen regio's.

U kunt kiezen tussen verschillende typen clusterconfiguraties voor meerdere regio's, die elk verschillende niveaus van hersteltijd ondersteunen, mogelijk gegevensverlies, inspanning en kosten. Selecteer Azure regio's voor elk cluster dat ondersteuning biedt voor de vereisten voor latentie en gegevenslocatie. Zie Overzicht van bedrijfscontinuïteit en noodherstel voor meer informatie over configuraties van multiregio-clusters en patronen die u kunt volgen.

Backups en herstel

Voor de meeste oplossingen hoeft u niet uitsluitend te vertrouwen op back-ups. Gebruik in plaats daarvan de andere mogelijkheden die in deze handleiding worden beschreven om uw tolerantievereisten te ondersteunen. Back-ups beschermen echter tegen enkele risico's die andere benaderingen niet opleveren. Zie Wat zijn redundantie, replicatie en back-up? voor meer informatie.

Azure Data Explorer biedt geen systeemeigen back-up- en herstelmogelijkheid. Als u een back-up van uw gegevens wilt maken, kunt u de volgende methoden overwegen:

• Continu exporteren exporteert periodiek gegevens naar externe opslag en biedt exact eenmalige export voor ondersteunde gegevenstypen.

• Gegevensexport naar cloudopslag ondersteunt het handmatig exporteren van gegevens naar externe opslag.

• Neem onbewerkte gegevens op in Azure Data Explorer vanuit een upstreambron, zoals een data lake, die u afzonderlijk kunt back-uppen.

Veerkracht tegen onbedoeld verwijderen

Azure Data Explorer bevat verschillende mechanismen om u te beschermen tegen onbedoeld verwijderen van clusters, databases, tabellen en externe tabellen:

• Onbedoeld cluster- of databaseverwijdering: Onbedoeld cluster- of databaseverwijdering is een onherstelbare actie. Voorkom gegevensverlies door een verwijderingsvergrendeling in te schakelen op het cluster of de databaseresource.

• Onopzettelijke tabelverwijdering: Gebruikers met beheerdersmachtigingen voor tabellen of hoger mogen tabellen verwijderen. Als een van deze gebruikers per ongeluk een tabel verwijdert, kunt u deze herstellen met behulp van de opdracht Tabel ongedaan maken . Als u deze opdracht wilt voltooien, moet u eerst de eigenschap herstelbaarheid inschakelen in het bewaarbeleid.

• Onbedoeld verwijderen van externe tabellen:externe tabellen zijn Kusto-queryschema-entiteiten die verwijzen naar gegevens die buiten de database zijn opgeslagen. Als u een externe tabel verwijdert, worden alleen de metagegevens van de tabel verwijderd. U kunt deze herstellen door de opdracht voor het maken van de tabel opnieuw uit te voeren.

  Voor externe azure Blob Storage- en Azure Data Lake-tabellen gebruikt u de mogelijkheid voor voorlopig verwijderen om te beschermen tegen onbedoeld verwijderen of overschrijven van een blob voor een door de gebruiker geconfigureerde hoeveelheid tijd.

Tolerantie voor serviceonderhoud

Azure Data Explorer past regelmatig service-updates toe en voert routineonderhoud uit. Het Azure-platform verwerkt deze activiteiten automatisch en blijft binnen de beschikbaarheidsniveaus die zijn opgegeven in de SLA. Zorg ervoor dat uw toepassingen zijn voorbereid op incidenteel verlies in connectiviteit tijdens serviceonderhoud door de richtlijnen voor het afhandelen van tijdelijke fouten te volgen.

Gebruik Azure Service Health voor meer informatie over gepland onderhoud.

Diensteniveau-overeenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

Als u in aanmerking wilt komen voor de SLA voor beschikbaarheid van Azure Data Explorer, moet uw toepassing tijdelijke fouten afhandelen door mislukte aanvragen opnieuw uit te voeren.

Verwante inhoud

• Betrouwbaarheid in Azure
• Overzicht van Azure Data Explorer
• Overzicht van BCDR