Wat is herstel na noodgeval?
Een noodgeval is één belangrijke gebeurtenis met een grotere en langere impact dan een toepassing kan beperken door het onderdeel hoge beschikbaarheid van het ontwerp. Herstel na noodgevallen (DR) gaat over herstel na gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties, die leiden tot downtime en gegevensverlies. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt.
Hersteldoelstellingen
Een volledig DR-plan moet de volgende kritieke bedrijfsvereisten opgeven voor elk proces dat door de toepassing wordt geïmplementeerd:
Recovery Point Objective (RPO) is de maximale duur van acceptabel gegevensverlies. RPO wordt gemeten in tijdseenheden, niet volume, zoals '30 minuten aan gegevens' of 'vier uur aan gegevens'. RPO gaat over het beperken en herstellen van gegevensverlies, niet gegevensdiefstal.
Recovery Time Objective (RTO) is de maximale duur van acceptabele downtime, waarbij 'downtime' wordt gedefinieerd door uw specificatie. Als de acceptabele downtime in een noodgeval bijvoorbeeld acht uur is, is de RTO acht uur.
Elk belangrijk proces of elke belangrijke workload die door een toepassing wordt geïmplementeerd, moet afzonderlijke RPO- en RTO-waarden hebben door de risico's en mogelijke herstelstrategieën voor noodgevallen te onderzoeken. Het proces voor het opgeven van een RPO en RTO maakt effectief DR-vereisten voor uw toepassing als gevolg van uw unieke zakelijke zorgen (kosten, impact, gegevensverlies, enzovoort).
Ontwerpen voor herstel na noodgeval
Herstel na noodgevallen is geen automatische functie, maar moet worden ontworpen, gebouwd en getest. Ter ondersteuning van een solide DR-strategie moet u vanaf de basis een toepassing bouwen met dr. Azure biedt services, functies en richtlijnen om u te helpen bij het ondersteunen van herstel na noodgevallen bij het maken van apps.
Gegevensherstel
Tijdens een noodgeval zijn er twee belangrijke methoden voor het herstellen van gegevens: back-ups en replicatie.
Back-up herstelt gegevens naar een bepaald tijdstip. Door back-up te gebruiken, kunt u eenvoudige, veilige en rendabele oplossingen bieden voor het maken van back-ups en het herstellen van uw gegevens naar de Microsoft Azure-cloud. Gebruik Azure Backup om langdurige, alleen-lezen gegevensmomentopnamen te maken voor gebruik in herstel.
Gegevensreplicatie maakt realtime of bijna realtime kopieën van live gegevens in meerdere replica's van gegevensarchieven met minimale gegevensverlies in gedachten. Het doel van replicatie is het synchroniseren van de replica’s met zo min mogelijk latentie en met behoud van de reactiesnelheid van de toepassing. De meeste volledig functionele databasesystemen en andere producten en services voor gegevensopslag omvatten een soort replicatie als een nauw geïntegreerde functie, vanwege de functionele en prestatievereisten. Een voorbeeld hiervan is geografisch redundante opslag (GRS).
Verschillende replicatieontwerpen plaatsen verschillende prioriteiten voor gegevensconsistentie, prestaties en kosten.
Actieve replicatie vereist dat er gelijktijdig updates worden uitgevoerd op meerdere replica's tegelijk, wat consistentie garandeert ten koste van doorvoer.
Passieve replicatie voert synchronisatie op de achtergrond uit, waardoor replicatie wordt verwijderd als een beperking voor de prestaties van toepassingen, maar het verhogen van de RPO.
Active-active - of multimaster-replicatie maakt het mogelijk om meerdere replica's tegelijk te gebruiken, waardoor taakverdeling mogelijk is ten koste van het compliceren van gegevensconsistentie.
Actief-passieve replicatie reserveert replica's voor live gebruik alleen tijdens failover.
Notitie
De meeste volledig functionele databasesystemen en andere gegevensopslagproducten en -services omvatten een soort replicatie, zoals geografisch redundante opslag (GRS), vanwege hun functionele en prestatievereisten.
Tolerante toepassingen bouwen
Scenario's voor noodgevallen leiden meestal ook tot downtime, of dit nu het gevolg is van netwerkverbindingsproblemen, datacenterstoringen, beschadigde virtuele machines (VM's) of beschadigde software-implementaties. In de meeste gevallen omvat toepassingsherstel een failover naar een afzonderlijke, werkende implementatie. Als gevolg hiervan kan het nodig zijn om processen in een andere Azure-regio te herstellen in het geval van een grootschalige noodgeval. Aanvullende overwegingen kunnen zijn: herstellocaties, het aantal gerepliceerde omgevingen en het onderhouden van deze omgevingen.
Afhankelijk van uw toepassingsontwerp kunt u verschillende strategieën en Azure-functies, zoals Azure Site Recovery, gebruiken om de ondersteuning van uw toepassing voor procesherstel na een noodgeval te verbeteren.
Servicespecifieke functies voor herstel na noodgevallen
De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service), zoals Azure-app Service, bieden functies en richtlijnen ter ondersteuning van herstel na noodgevallen. Voor sommige scenario's kunt u servicespecifieke functies gebruiken om snel herstel te ondersteunen. Zo ondersteunt Azure SQL Server geo-replicatie voor het snel herstellen van de service in een andere regio. Azure App Service bevat een functie voor back-up en herstel, en de documentatie biedt hulp voor het gebruik van Azure Traffic Manager om verkeer naar een secundaire regio te routeren.