Overzicht van bedrijfscontinuïteit en herstel na noodgevallen

Bedrijfscontinuïteit en het herstel na noodgevallen in Azure Data Explorer stellen uw bedrijf in staat om door te blijven opereren bij een verstoring. In dit artikel worden meerdere configuraties voor herstel na noodgevallen beschreven, afhankelijk van vereisten voor herstelbaarheid (RPO en RTO), benodigde inspanningen en kosten.

Zie Betrouwbaarheid in Azure Data Explorer voor meer informatie over de betrouwbaarheidsopties die beschikbaar zijn voor Azure Data Explorer, waaronder beschikbaarheidszoneondersteuning, back-up en bescherming tegen bepaalde soorten menselijke fouten.

Configuraties voor herstel na noodgevallen

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:

• Active-Active-Active (always-on) configuratie
• configuratie vanActive-Active
• Active-Hot stand-by configuratie
• Clusterconfiguratie voor gegevensherstel op aanvraag

Actief-actief-configuratie

Deze configuratie wordt ook wel always-on genoemd. Voor kritieke toepassingsimplementaties zonder tolerantie voor storingen moet u meerdere Azure Data Explorer clusters in Azure gekoppelde regio's gebruiken. 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 Azure gekoppelde regio's. Een Azure regiostoring veroorzaakt geen storing in een toepassing. Mogelijk ondervindt u enige latentie of prestatievermindering.

configuratie van Active-Active

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

Active-Hot standbyconfiguratie

De Active-Hot-configuratie is vergelijkbaar met de Active-Active-configuratie in dubbele data-invoer, verwerking en curatie. Hoewel het standby cluster online is voor data-opname, verwerking en curatie, is het niet beschikbaar voor het uitvoeren van query's. 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 minst herstelbaarheid (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 opgestart 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 ondersteunt crosscluster-joins. 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