Bedrijfscontinuïteit en herstel na noodgevallen voor analyses op cloudschaal
Wanneer u een architectuur voor een cloudservice ontwerpt, moet u rekening houden met uw beschikbaarheidsvereisten en hoe u kunt reageren op mogelijke onderbrekingen in de service. Een probleem kan worden gelokaliseerd naar het specifieke exemplaar of regiobreed. Plannen hebben voor beide is belangrijk. Afhankelijk van uw beoogde hersteltijd en het beoogde herstelpunt, kunt u een agressieve strategie kiezen voor hoge beschikbaarheid en herstel na noodgevallen.
Hoge beschikbaarheid en herstel na noodgevallen kunnen soms worden gecombineerd. De twee gebieden hebben iets verschillende strategieën, vooral als het gaat om gegevens. Zie Microsoft Azure Well-Architected Framework en de bijbehorende betrouwbaarheidsprincipes voor meer informatie.
In plaats van te proberen fouten te voorkomen, accepteert u van tevoren dat fouten kunnen en kunnen optreden. Minimaliseer de effecten van een enkel defect onderdeel in de levenscyclus. Uw tolerantie voor kosten, het beoogde herstelpunt en de beoogde hersteltijd bepalen het type oplossing dat moet worden geïmplementeerd.
Back-upstrategieën
Er zijn veel alternatieve strategieën beschikbaar voor het implementeren van gedistribueerde rekenkracht tussen regio's. Strategieën moeten worden afgestemd op de bedrijfsvereisten en -omstandigheden van uw toepassing. Op hoog niveau vallen de benaderingen in de volgende categorieën:
Back-up maken en herstellen: Herstel de databasetoepassing van de laatste back-upkopie vóór het noodgeval. Deze methode wordt vaak gebruikt na beschadiging van gegevens of onbedoelde verwijdering.
Opnieuw implementeren bij noodgeval: Implementeer de toepassing opnieuw op het moment van een noodgeval. Deze aanpak is geschikt voor niet-kritieke toepassingen waarvoor geen gegarandeerde hersteltijd is vereist.
Warm reserve (actief/passief): Maak een secundaire gehoste service in een alternatieve regio. Rollen implementeren om minimale capaciteit te garanderen. De rollen ontvangen geen productieverkeer. Deze aanpak is handig voor toepassingen die niet zijn ontworpen voor het distribueren van verkeer tussen regio's.
Hot spare (actief/actief): Ontwerp de toepassing om productiebelasting in meerdere regio's te ontvangen. U kunt de cloudservices in elke regio configureren voor een hogere capaciteit dan nodig is voor herstel na noodgevallen. In plaats daarvan kunt u de cloudservices naar behoefte uitschalen op het moment van een noodgeval en failover.
Deze benadering vereist investeringen in het toepassingsontwerp, maar heeft voordelen. Het biedt lage en gegarandeerde hersteltijd. Er wordt continu getest op alle herstellocaties en efficiënt gebruik van de capaciteit. Voor databasetoepassingen omvat deze benadering een load balancer voor twee databases die worden gesynchroniseerd met één verbindingspunt.
Herstel na noodgevallen en hoge beschikbaarheid voor Azure-services
In de volgende secties worden verschillende Azure-services besproken.
Azure Cosmos DB
Zie Hoe biedt Azure Cosmos DB hoge beschikbaarheid voor een overzicht van hoge beschikbaarheid met Azure Cosmos DB.
Azure Data Factory
Voor gegevensintegraties en gegevensproducten zijn waarschijnlijk Azure DevOps-opslagplaatsen gekoppeld aan Azure Data Factory. U kunt pijplijnen implementeren in een andere Data Factory met minimale downtime. Als u software voor codeversiebeheer wilt gebruiken naast GitHub en Azure DevOps-opslagplaats, gebruikt u de Azure Data Factory SDK om pijplijnen en andere Azure Data Factory objecten te maken.
Azure Data Lake
Azure Data Lake Storage Gen2 ondersteunt al 3x-replicatie om u te beschermen tegen gelokaliseerde hardwarefouten. Andere replicatieopties, zoals zone-redundante opslag (ZRS) of geografisch zone-redundante opslag (GZRS), verbeteren de hoge beschikbaarheid. Geografisch redundante opslag (GRS) en geografisch redundante opslag met leestoegang (RA-GRS) verbeteren herstel na noodgevallen. Als er een serviceonderbreking is voor hoge beschikbaarheid, moet de workload zo snel mogelijk toegang hebben tot de meest recente gegevens. De workload kan lokaal of naar een nieuwe regio overschakelen naar een gerepliceerd exemplaar.
Een opslagaccount dat is geconfigureerd als RA-GRS of GRS, kan deel uitmaken van een noodherstelplan, maar vereist zorgvuldige analyse van RPO (Recovery Point Objective) en Recovery Time Objective (RTO) en het beoordelen van andere opties, zoals een scenario met dubbele belasting waarbij gegevens naar twee verschillende Azure-regio's worden gekopieerd.
Elke gegevenslandingszone moet een herstelpuntdoelstelling hebben voor de bijbehorende gegevensproducten. Elke gegevenslandingszone moet een gedefinieerde replicatiestrategie hebben voor de gebruiksscenario's.
Notitie
Door de klant beheerde accountfailover wordt nog niet ondersteund in accounts met een hiërarchische naamruimte (Azure Data Lake Storage Gen2).
In het geval van een noodgeval dat van invloed is op de primaire regio, beheert Microsoft de failover voor accounts met een hiërarchische naamruimte.
Zie Herstel na noodgeval en failover van opslagaccounts voor meer informatie.
Azure Databricks
Azure Machine Learning
Zie Failover voor bedrijfscontinuïteit en herstel na noodgevallen voor een overzicht van hoge beschikbaarheid met Azure Machine Learning.
Azure Key Vault
Azure Key Vault biedt functies om de beschikbaarheid te behouden en gegevensverlies te voorkomen. Maak alleen back-ups van geheimen als dit vanuit bedrijfsoogpunt noodzakelijk is. Het maken van back-ups van geheimen in uw sleutelkluis kan operationele uitdagingen met zich mee brengen, zoals het onderhouden van meerdere sets logboeken, machtigingen en back-ups wanneer geheimen verlopen of roteren. Zie Back-up van Azure Key Vault voor meer informatie.
Key Vault behoudt beschikbaarheid in noodscenario's. Er wordt een failover uitgevoerd voor aanvragen naar een gekoppelde regio zonder tussenkomst van een gebruiker. Zie Beschikbaarheid en redundantie in Azure Key Vault voor meer informatie. Als alternatief kunt u overwegen geheimen en andere Key Vault artefacten op te slaan in een secundaire kluis met de juiste machtigingen. Dit patroon kan geschikt zijn voor toepassingen waarvoor de kluis zich in dezelfde regio als de toepassing moet bevinden.
Azure SQL Database
Azure Synapse Analytics
Volgende stappen
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor