Overzicht van bedrijfscontinuïteit met Azure SQL Database
Van toepassing op:
Azure SQL Database
Dit artikel bevat een overzicht van de mogelijkheden voor bedrijfscontinuïteit en herstel na noodgevallen van Azure SQL Database, waarin de opties en aanbevelingen worden beschreven voor het herstellen van verstorende gebeurtenissen die kunnen leiden tot gegevensverlies of waardoor uw database en toepassing niet meer beschikbaar zijn. Meer informatie over wat u moet doen wanneer een gebruiker of toepassingsfout van invloed is op de gegevensintegriteit, een Azure-beschikbaarheidszone of -regio heeft een storing of dat uw toepassing onderhoud vereist.
Overzicht
Bedrijfscontinuïteit in Azure SQL Database verwijst naar de mechanismen, beleidsregels en procedures waarmee uw bedrijf kan blijven werken in het gezicht van onderbrekingen door beschikbaarheid, hoge beschikbaarheid en herstel na noodgevallen te bieden.
In de meeste gevallen verwerkt SQL Database verstorende gebeurtenissen die zich in een cloudomgeving kunnen voordoen en blijven uw toepassingen en bedrijfsprocessen actief. Er zijn echter enkele verstorende gebeurtenissen waarbij het beperken enige tijd kan duren, zoals:
- Gebruiker verwijdert of werkt per ongeluk een rij in een tabel bij.
- Kwaadwillende aanvaller verwijdert gegevens of verwijdert een database.
- Een catastrofale natuurramp neemt een datacenter of beschikbaarheidszone of regio uit.
- Zeldzame datacenter-, beschikbaarheidszone- of regiobrede storing veroorzaakt door een configuratiewijziging, softwarefout of hardwareonderdeelfout.
Beschikbaarheid
Azure SQL Database wordt geleverd met een kerntolerantie en betrouwbaarheidsbelofte die deze beschermt tegen software- of hardwarefouten. Databaseback-ups worden geautomatiseerd om uw gegevens te beschermen tegen beschadiging of onbedoeld verwijderen. Als PaaS (Platform-as-a-Service) biedt de Azure SQL Database-service beschikbaarheid als een standaardfunctie met een toonaangevende SLA voor beschikbaarheid van 99,99%.
Hoge beschikbaarheid
Als u hoge beschikbaarheid wilt bereiken in de Azure-cloudomgeving, schakelt u zoneredundantie in zodat de database of elastische pool beschikbaarheidszones gebruikt om ervoor te zorgen dat de database of elastische pool bestand is tegen zonegebonden fouten. Veel Azure-regio's bieden beschikbaarheidszones, die gescheiden groepen datacenters zijn binnen een regio met onafhankelijke energie-, koelings- en netwerkinfrastructuur. Beschikbaarheidszones zijn ontworpen om regionale services, capaciteit en hoge beschikbaarheid in de resterende zones te bieden als één zone een storing ondervindt. Door zoneredundantie in te schakelen, is de database of elastische pool bestand tegen zonegebonden hardware- en softwarefouten en is het herstel transparant voor toepassingen. Wanneer hoge beschikbaarheid is ingeschakeld, kan de Azure SQL Database-service een SLA met een hogere beschikbaarheid van 99,995% bieden.
Herstel na noodgeval
Als u een hogere beschikbaarheid en redundantie in verschillende regio's wilt bereiken, kunt u mogelijkheden voor herstel na noodgevallen inschakelen om de database snel te herstellen na een catastrofale regionale storing. Opties voor herstel na noodgevallen met Azure SQL Database zijn:
- Met actieve geo-replicatie kunt u een continu gesynchroniseerde, leesbare secundaire database maken in elke regio voor een primaire database.
- Failovergroepen, naast het bieden van continue synchronisatie tussen een primaire en secundaire database, kunt u ook de replicatie en failover van sommige, of alle, databases op een logische server naar een secundaire logische server in een andere regio beheren. Failovergroepen bieden alleen-lezen en alleen-lezen-listener-eindpunten die ongewijzigd blijven, zodat het bijwerken van de toepassing verbindingsreeks s na failover niet nodig is.
- Met geo-herstel kunt u herstellen vanuit een regionale storing door back-ups met geo-replicatie te herstellen wanneer u geen toegang hebt tot uw database in de primaire regio door een nieuwe database te maken op een bestaande server in een Azure-regio.
De volgende tabel vergelijkt actieve geo-replicatie en failovergroepen, twee opties voor herstel na noodgevallen voor Azure SQL Database:
| Actieve geo-replicatie | Failovergroepen | |
|---|---|---|
| Continue gegevenssynchronisatie tussen primaire en secundaire gegevens | Ja | Ja |
| Gelijktijdig een failover uitvoeren voor meerdere databases | Nr. | Ja |
| Verbinding maken iontekenreeks blijft ongewijzigd na een failover | Nr. | Ja |
| Ondersteunt leesschaal | Ja | Ja |
| Meerdere replica's | Ja | Nr. |
| Kan zich in dezelfde regio bevinden als primair | Ja | Nr. |
Functies die bedrijfscontinuïteit bieden
Vanuit databaseperspectief zijn er vier belangrijke scenario's voor mogelijke onderbrekingen. De volgende tabel bevat functies voor bedrijfscontinuïteit van SQL Database die u kunt gebruiken om een mogelijk scenario voor bedrijfsonderbreking te beperken:
| Scenario voor bedrijfsonderbreking | Bedrijfscontinuïteitsfunctie |
|---|---|
| Lokale hardware- of softwarefouten die van invloed zijn op het databaseknooppunt. | Om lokale hardware- en softwarefouten te beperken, bevat SQL Database een beschikbaarheidsarchitectuur, die automatisch herstel van deze fouten garandeert met een SLA van maximaal 99,99% beschikbaarheid. |
| Gegevensbeschadiging of -verwijdering, meestal veroorzaakt door een fout of menselijke fout in de toepassing. Dergelijke fouten zijn toepassingsspecifiek en kunnen doorgaans niet worden gedetecteerd door de databaseservice. | Om uw bedrijf te beschermen tegen gegevensverlies, maakt SQL Database elke 12 of 24 uur automatisch volledige databaseback-ups, differentiële databaseback-ups en elke 5 tot 10 minuten back-ups van transactielogboeken. Standaard worden back-ups gedurende zeven dagen opgeslagen in geografisch redundante opslag voor alle servicelagen. Alle servicelagen behalve Basic ondersteunen een configureerbare bewaarperiode voor back-ups voor herstel naar een bepaald tijdstip (PITR) van maximaal 35 dagen. U kunt een verwijderde database herstellen naar het punt waarop deze is verwijderd als de server niet is verwijderd of als u langetermijnretentie (LTR) hebt geconfigureerd. |
| Zeldzame storingen in datacenters of beschikbaarheidszones, mogelijk veroorzaakt door een natuurramp, configuratiewijziging, softwarefout of storing van hardwareonderdelen. | Als u de storing op datacenter- of beschikbaarheidszoneniveau wilt beperken, schakelt u zoneredundantie in voor de database of elastische pool om Azure Beschikbaarheidszones te gebruiken en redundantie te bieden voor meerdere fysieke zones binnen een Azure-regio. Het inschakelen van zoneredundantie zorgt ervoor dat de database of elastische pool bestand is tegen zonefouten met een SLA van maximaal 99,995% hoge beschikbaarheid. |
| Zeldzame regionale storingen die van invloed zijn op alle beschikbaarheidszones en de datacenters die deze omvatten, mogelijk veroorzaakt door een catastrofale natuurramp. | Als u een storing in de hele regio wilt beperken, schakelt u herstel na noodgevallen in met behulp van een van de opties: - Opties voor continue gegevenssynchronisatie, zoals failovergroepen (aanbevolen) of actieve geo-replicatie waarmee u replica's in een secundaire regio kunt maken voor failover. - Back-upopslagredundantie instellen op geografisch redundante back-upopslag om geo-herstel te gebruiken. |
Beoogde hersteltijd en beoogd herstelpunt
Wanneer u uw bedrijfscontinuïteitsplan ontwikkelt, begrijpt u de maximaal acceptabele tijd voordat de toepassing volledig wordt hersteld na de verstorende gebeurtenis. De tijd die nodig is voor een toepassing om volledig te herstellen, wordt de RTO (Recovery Time Objective) genoemd. Begrijp ook de maximale periode van recente gegevensupdates (tijdsinterval) die de toepassing kan verdragen bij het herstellen van een niet-geplande verstorende gebeurtenis. Het potentiële gegevensverlies wordt RPO (Recovery Point Objective) genoemd.
In de volgende tabel worden RPO en RTO van elke optie voor bedrijfscontinuïteit vergeleken:
| Optie voor bedrijfscontinuïteit | RTO (downtime) | RPO (gegevensverlies) |
|---|---|---|
| Hoge beschikbaarheid (zoneredundantie inschakelen) |
Doorgaans minder dan 30 seconden | 0 |
| Herstel na noodgevallen (failovergroepen of actieve geo-replicatie inschakelen) |
Doorgaans minder dan 60 seconden | Gelijk aan of groter dan 0 (afhankelijk van gegevenswijzigingen vóór de verstorende gebeurtenis die niet is gerepliceerd) |
| Herstel na noodgevallen (met geo-herstel) |
Meestal minuten of uren | Meestal minuten of uren |
Controlelijsten voor bedrijfscontinuïteit
Raadpleeg het volgende voor prescriptieve aanbevelingen om de beschikbaarheid te maximaliseren en een hogere bedrijfscontinuïteit te bereiken:
- Beschikbaarheidscontrolelijst
- Controlelijst voor hoge beschikbaarheid
- Controlelijst voor herstel na noodgevallen
Voorbereiden op een regiostoring
Ongeacht welke functies voor bedrijfscontinuïteit u gebruikt, moet u de secundaire database in een andere regio voorbereiden. Als u zich niet goed voorbereidt, neemt het online brengen van uw toepassingen na een failover of herstel extra tijd in beslag en vereist waarschijnlijk ook probleemoplossing, waardoor RTO kan worden vertraagd. Volg de controlelijst voor het voorbereiden van secundaire regio-storingen.
Een database binnen dezelfde Azure-regio herstellen
U kunt automatische databaseback-ups gebruiken om een database te herstellen naar een bepaald tijdstip in het verleden. Op deze manier kunt u gegevensbeschadigingen herstellen die worden veroorzaakt door menselijke fouten. Met herstel naar een bepaald tijdstip (PITR) kunt u een nieuwe database maken op dezelfde server die de status van gegevens vertegenwoordigt vóór de beschadigde gebeurtenis. Voor de meeste databases duurt het minder dan 12 uur voor herstelbewerkingen. Het kan langer duren om een zeer grote of zeer actieve database te herstellen. Zie de hersteltijd van de database voor meer informatie.
Als de maximaal ondersteunde bewaarperiode voor back-ups voor herstel naar een bepaald tijdstip niet voldoende is voor uw toepassing, kunt u deze uitbreiden door een langetermijnretentiebeleid (LTR) voor de database(s) te configureren. Zie Langetermijnretentie van back-ups voor meer informatie.
Een toepassing upgraden met minimale uitvaltijd
Soms moet een toepassing offline worden gehaald vanwege onderhoud, zoals een upgrade van een toepassing. Bij het beheren van toepassingsupgrades wordt beschreven hoe u actieve geo-replicatie gebruikt om rolling upgrades van uw cloudtoepassing in te schakelen om downtime tijdens upgrades te minimaliseren en een herstelpad te bieden als er iets misgaat.
Besparen op kosten met een stand-byreplica
Als uw secundaire replica alleen wordt gebruikt voor herstel na noodgevallen en geen lees- of schrijfworkloads heeft, kunt u besparen op licentiekosten door de database voor stand-by aan te wijzen wanneer u een nieuwe actieve geo-replicatierelatie configureert.
Bekijk licentievrije stand-byreplica voor meer informatie.
Volgende stappen
Zie Een toepassing ontwerpen voor noodherstel in de cloud en strategieën voor herstel na noodgevallen voor elastische pools voor overwegingen bij het ontwerpen van toepassingen.
Bekijk de richtlijnen voor herstel na noodgevallen van Azure SQL Database en de controlelijst voor hoge beschikbaarheid en herstel na noodgevallen van Azure SQL Database.