Overzicht van bedrijfscontinuïteit en herstel na noodgevallen

Dankzij bedrijfscontinuïteit en herstel na noodgevallen in Azure Data Explorer kan uw bedrijf blijven werken in het gezicht van een onderbreking. In dit artikel worden beschikbaarheid (binnen regio' s) en herstel na noodgevallen besproken. Het bevat informatie over systeemeigen mogelijkheden en overwegingen met betrekking tot architectuur voor een flexibele Implementatie van Azure Data Explorer. Het bevat informatie over herstel van menselijke fouten, hoge beschikbaarheid, gevolgd door meerdere configuraties voor herstel na noodgevallen. Deze configuraties zijn afhankelijk van tolerantievereisten zoals Recovery Point Objective (RPO) en Recovery Time Objective (RTO), benodigde inspanningen en kosten.

Verstorende gebeurtenissen beperken

• Menselijke fout
• Hoge beschikbaarheid van Azure Data Explorer
• Storing in een Azure-beschikbaarheidszone
• Storing in een Azure-datacenter
• Storing in een Azure-regio

Menselijke fout

Menselijke fouten zijn onvermijdelijk. Gebruikers kunnen per ongeluk een cluster, database of tabel verwijderen.

Onopzettelijke cluster- of databaseverwijdering

Onbedoeld cluster- of databaseverwijdering is een onherstelbare actie. Als eigenaar van de Azure Data Explorer-resource kunt u gegevensverlies voorkomen door de mogelijkheid voor verwijderenvergrendeling in te schakelen, beschikbaar op azure-resourceniveau.

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 .undo drop table opdracht. Als u deze opdracht wilt uitvoeren, 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. Gebruik de functie voor voorlopig verwijderen om te beschermen tegen onbedoeld verwijderen of overschrijven van een bestand/blob voor een door de gebruiker geconfigureerde hoeveelheid tijd.

Hoge beschikbaarheid van Azure Data Explorer

Hoge beschikbaarheid verwijst naar de fouttolerantie van Azure Data Explorer, de bijbehorende onderdelen en onderliggende afhankelijkheden binnen een Azure-regio. Deze fouttolerantie voorkomt single points of failure (SPOF) in de implementatie. In Azure Data Explorer omvat hoge beschikbaarheid de persistentielaag, de rekenlaag en een configuratie van een leidervolger.

Persistentielaag

Azure Data Explorer maakt gebruik van Azure Storage als duurzame persistentielaag. Azure Storage 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. Verdere tolerantie is mogelijk met Zone Redundant Storage (ZRS) die replica's intelligent plaatst in regionale beschikbaarheidszones van Azure voor maximale fouttolerantie tegen extra kosten. ZRS-opslag wordt automatisch geconfigureerd wanneer het Azure Data Explorer-cluster wordt geïmplementeerd in beschikbaarheidszones.

Rekenlaag

Azure Data Explorer is een gedistribueerd computingplatform en kan twee tot veel knooppunten hebben, afhankelijk van het schaal- en knooppuntroltype. Selecteer op het moment van inrichten beschikbaarheidszones om de knooppuntimplementatie te distribueren, tussen zones voor maximale tolerantie binnen regio's. Een fout in de beschikbaarheidszone resulteert niet in een volledige storing, maar in plaats daarvan worden de prestaties afgebroken totdat de zone wordt hersteld.

Configuratie van leader-volgercluster

Azure Data Explorer biedt een optionele volgmogelijkheid voor een leidercluster dat moet worden gevolgd door andere volgclusters voor alleen-lezentoegang tot de gegevens en metagegevens van de leider. Wijzigingen in de leider, zoals create, appenden drop worden automatisch gesynchroniseerd met de volger. Hoewel de leiders Azure-regio's kunnen omvatten, moeten de volgclusters worden gehost in dezelfde regio's als de leider. Als het leidercluster niet beschikbaar is of databases of tabellen per ongeluk worden verwijderd, hebben de volgerclusters geen toegang meer totdat de toegang in de leider is hersteld.

Storing in een Azure-beschikbaarheidszone

Azure-beschikbaarheidszones zijn unieke fysieke locaties binnen dezelfde Azure-regio. Ze kunnen de rekenkracht en gegevens van een Azure Data Explorer-cluster beveiligen tegen gedeeltelijke regiofouten. Zonefout is een beschikbaarheidsscenario, omdat het een intraregio is.

Maak een Azure Data Explorer-cluster vast aan dezelfde zone als andere verbonden Azure-resources. Zie Een cluster maken voor meer informatie over het inschakelen van beschikbaarheidszones.

Storing in een Azure-datacenter

Azure-beschikbaarheidszones worden geleverd met kosten en sommige klanten kiezen ervoor om te implementeren zonder zonegebonden redundantie. Bij een dergelijke implementatie van Azure Data Explorer leidt een storing in een Azure-datacenter tot clusterstoring. Het verwerken van een storing in een Azure-datacenter is daarom identiek aan die van een Azure-regiostoring.

Storing in een Azure-regio

Azure Data Explorer biedt geen automatische beveiliging tegen de storing van een hele Azure-regio. Om de bedrijfsimpact te minimaliseren als er sprake is van een dergelijke storing, zijn er meerdere Azure Data Explorer-clusters in gekoppelde Azure-regio's. Op basis van uw beoogde hersteltijd (RTO), RPO (Recovery Point Objective), evenals overwegingen voor inspanning en kosten, zijn er meerdere configuraties voor herstel na noodgevallen. Kosten- en prestatieoptimalisaties zijn mogelijk met aanbevelingen van Azure Advisor en configuratie voor automatische schaalaanpassing .

Configuraties voor herstel na noodgevallen

In deze sectie worden meerdere configuraties voor herstel na noodgevallen beschreven, afhankelijk van de tolerantievereisten (RPO en RTO), de benodigde inspanningen en kosten.

RTO (Recovery Time Objective) verwijst naar de tijd die nodig is om te herstellen na een onderbreking. RTO van 2 uur betekent bijvoorbeeld dat de toepassing binnen twee uur na een onderbreking actief moet zijn. RPO (Recovery Point Objective) verwijst naar het tijdsinterval dat kan worden doorgegeven tijdens een onderbreking voordat de hoeveelheid gegevens die tijdens die periode verloren gaat, groter is dan de toegestane drempelwaarde. Als de RPO bijvoorbeeld 24 uur is en een toepassing gegevens bevat die beginnen vanaf 15 jaar geleden, bevinden ze zich nog steeds binnen de parameters van de overeengekomen RPO.

Opname-, verwerkings- en curatieprocessen moeten vooraf zorgvuldig worden ontworpen bij het plannen van herstel na noodgevallen. Opname verwijst naar gegevens die zijn geïntegreerd in Azure Data Explorer uit verschillende bronnen; verwerking verwijst naar transformaties en soortgelijke activiteiten; curatie verwijst naar gerealiseerde weergaven, exporteert naar de data lake, enzovoort.

Hier volgen populaire configuraties voor herstel na noodgevallen:

• Configuratie van actiefActive-Active (always-on)
• configuratie vanActive-Active
• Active-Hot stand-byconfiguratie
• Clusterconfiguratie voor gegevensherstel op aanvraag

Actief-actief-configuratie

Deze configuratie wordt ook wel always-on genoemd. Gebruik voor kritieke toepassingsimplementaties zonder tolerantie voor storingen meerdere Azure Data Explorer-clusters in gekoppelde Azure-regio's. Stel opname, verwerking en curatie parallel in voor alle clusters. De cluster-SKU moet hetzelfde zijn tussen regio's. Azure zorgt ervoor dat updates worden geïmplementeerd en verspreid over gekoppelde Azure-regio's. Een storing in een Azure-regio veroorzaakt geen storing in een toepassing. Mogelijk ondervindt u enige latentie of prestatievermindering.

configuratie van Active-Active

Deze configuratie is identiek aan de configuratie actief-actief-actief, maar er zijn slechts twee gekoppelde Azure-regio's. Configureer dubbele opname, verwerking en curatie. Gebruikers worden doorgestuurd naar de dichtstbijzijnde regio. De cluster-SKU moet hetzelfde zijn tussen regio's.

stand-byconfiguratie Active-Hot

De Active-Hot-configuratie is vergelijkbaar met de Active-Active-configuratie in dubbele opname, verwerking en curatie. Hoewel het stand-bycluster online is voor opname, proces en curatie, is het niet beschikbaar om query's uit te voeren. Het stand-bycluster hoeft zich niet in dezelfde SKU als het primaire cluster te bevinden. Het kan van een kleinere SKU en schaal zijn, wat ertoe kan leiden dat deze minder goed presteert. In een noodscenario worden gebruikers omgeleid naar het stand-bycluster, dat optioneel omhoog kan worden geschaald om de prestaties te verbeteren.

Configuratie voor gegevensherstel op aanvraag

Deze oplossing biedt de minste tolerantie (hoogste RPO en RTO), is de laagste kosten en de hoogste inspanning. In deze configuratie is er geen cluster voor gegevensherstel. Configureer continue export van gecureerde gegevens (tenzij onbewerkte en tussenliggende gegevens ook vereist zijn) naar een opslagaccount dat GRS (Geografisch redundante opslag) is geconfigureerd. Een cluster voor gegevensherstel wordt opgeslagen als er een noodherstelscenario is. Op dat moment worden DDLs, configuratie, beleid en processen toegepast. Gegevens worden opgenomen uit de opslag met de eigenschap kustoCreationTime voor opname om de opnametijd te overschrijven die standaard is ingesteld op systeemtijd.

Overzicht van configuratieopties voor herstel na noodgevallen

Beste praktijken

Volg deze aanbevolen procedures, ongeacht welke configuratie voor herstel na noodgevallen is gekozen:

• Alle databaseobjecten, beleidsregels en configuraties moeten worden bewaard in broncodebeheer, zodat ze vanuit het hulpprogramma voor releaseautomatisering kunnen worden vrijgegeven aan het cluster. Zie Azure DevOps-ondersteuning voor Azure Data Explorer voor meer informatie.
• Ontwerp, ontwikkel en implementeer validatieroutines om ervoor te zorgen dat alle clusters worden gesynchroniseerd vanuit het perspectief van gegevens. Azure Data Explorer biedt ondersteuning voor joins tussen clusters. Een eenvoudig aantal of rijen in verschillende tabellen kan helpen bij het valideren.
• Releaseprocedures moeten betrekking hebben op governancecontroles en -balansen die zorgen voor spiegeling van de clusters.
• Wees volledig op de hoogte van wat er nodig is om een volledig nieuw cluster te bouwen.
• Maak een controlelijst met implementatie-eenheden. Uw lijst is uniek voor uw behoeften, maar moet bestaan uit: implementatiescripts, opnameverbindingen, BI-hulpprogramma's en andere belangrijke configuraties.

Volgende stap