Bedrijfscontinuïteit en herstel na noodgevallen voor analyses op cloudschaal
Wanneer u 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 beperkt worden tot een specifiek geval of de gehele regio. Het is belangrijk om plannen voor beide te hebben. Afhankelijk van uw beoogde hersteltijd en de 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 de Microsoft Azure Well-Architected Framework- en de bijbehorende betrouwbaarheidsprincipesvoor meer informatie.
In plaats van fouten te voorkomen, accepteert u vooraf dat fouten wel en wel kunnen gebeuren. Minimaliseer de effecten van een onderdeel met één fout 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 in verschillende regio's. Strategieën moeten worden afgestemd op bedrijfsvereisten en -omstandigheden van uw toepassing. Op hoog niveau vallen de benaderingen in de volgende categorieën:
Backup en herstel: De databasetoepassing herstellen vanaf de laatste back-up vóór de ramp. Deze methode wordt vaak gebruikt na beschadiging van gegevens of onbedoeld verwijderen.
opnieuw implementeren bij noodgeval: de toepassing helemaal opnieuw implementeren op het moment van een noodgeval. Deze methode is geschikt voor niet-kritieke toepassingen waarvoor geen gegarandeerde hersteltijd is vereist.
Warme reserve (actief/passief): Een secundaire gehost service maken in een alternatieve regio. Implementeer rollen om minimale capaciteit te garanderen. De rollen ontvangen geen productieverkeer. Deze aanpak is handig voor toepassingen die niet zijn ontworpen om verkeer over regio's te verdelen.
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 vereist is voor herstel na noodgevallen. In plaats daarvan kunt u de cloudservices zo nodig uitschalen op het moment van een noodgeval en failover.
Deze aanpak vereist investeringen in het toepassingsontwerp, maar heeft voordelen. Het biedt een lage en gegarandeerde hersteltijd. Er wordt continu getest op alle herstellocaties en het efficiënte gebruik van 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
Cloud Scale Analytics bestaat uit verschillende Azure-services die zijn gegroepeerd in platform, kern en gegevens. Zie de documentatie azure-betrouwbaarheidsdocumentatie voor meer informatie over servicespecifieke betrouwbaarheidshandleidingen en herstel na noodgevallen
Volgende stappen
- Overzicht van gegevensbeheer