Overzicht van bedrijfscontinuïteit met Azure SQL Database
van toepassing op:
Azure SQL DatabaseSQL-database in Fabric
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 natuurrampgebeurtenis legt een datacenter, beschikbaarheidszone of regio plat.
- 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.
Noodherstel
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:
- Actieve geo-replicatie kunt u een continu gesynchroniseerde leesbare secundaire database maken in elke regio voor een primaire database.
- failovergroepen, naast continue synchronisatie tussen een primaire en secundaire database, kunt u ook de replicatie en failover van sommige of alle databases op een logische server beheren naar een secundaire logische server in een andere regio. Failovergroepen bieden lees-schrijf- en alleen-lezen-listener-eindpunten die ongewijzigd blijven, zodat het bijwerken van toepassingsverbindingsreeksen na failover niet nodig is.
- geo-herstel kunt u herstellen na een regionale storing door te herstellen vanuit geo-gerepliceerde back-ups 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 | Ja | Ja |
| Uitwijken naar meerdere databases tegelijk | Nee | Ja |
| verbindingsreeks blijft ongewijzigd na failover | Nee | Ja |
| ondersteunt lees-schaal | Ja | Ja |
| meerdere replica's | Ja | Nee |
| kan zich in dezelfde regio bevinden als de primaire | Ja | Nee |
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 maximaal 99,99% beschikbaarheids-SLA. |
| 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 opgeslagen in geografisch redundante opslag gedurende zeven dagen voor alle servicelagen. Alle serviceniveaus behalve Basic bieden ondersteuning voor een configureerbare bewaarperiode voor back-ups voor herstel op een specifiek tijdstip 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 storing op datacenter- of beschikbaarheidszoneniveau wilt beperken, schakelt u zoneredundantie voor de database of elastische pool in om Azure-beschikbaarheidszones te gebruiken en redundantie te bieden voor meerdere fysieke zones binnen een Azure-regio. Door zoneredundantie in te schakelen, zorgt u ervoor dat de database of elastische pool bestand is tegen zonefouten met maximaal 99.995% SLA voor hoge beschikbaarheid. |
| Zeldzame regionale storing die gevolgen heeft voor alle beschikbaarheidszones en de datacenters die deze storing 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 volgende 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-herstelte gebruiken. |
RTO en RPO
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 bedrijfscontinuïteit | RTO (uitval) | RPO (gegevensverlies) |
|---|---|---|
| Hoge beschikbaarheid (zoneredundantie gebruiken) |
Doorgaans minder dan 30 seconden | 0 |
| Rampenherstel (failover-groepen gebruiken met klantbeheerd failoverbeleid of actieve geo-replicatie) |
Doorgaans minder dan 60 seconden | Gelijk aan of groter dan 0 (is afhankelijk van gegevenswijzigingen vóór de verstorende gebeurtenis die niet is gerepliceerd) |
| Herstel na noodgevallen (met geo-herstel) |
Doorgaans minuten of uren, afhankelijk van Azure Storage-replicatie | Meestal minuten of uren, afhankelijk van de grootte van de back-up van de database |
Controlelijsten voor bedrijfscontinuïteit
Raadpleeg het volgende voor prescriptieve aanbevelingen om de beschikbaarheid te maximaliseren en een hogere bedrijfscontinuïteit te bereiken:
- controlelijst voor beschikbaarheid
- 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 checklist voor het voorbereiden van de secundaire systemen bij een regio-uitval.
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. Zie RTO en RPOvoor hersteltijden.
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-upsvoor meer informatie.
Een toepassing upgraden met minimale downtime
Soms moet een toepassing offline worden gehaald vanwege onderhoud, zoals een upgrade van een toepassing. Toepassingsupgrades beheren beschrijft 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.
Bespaar op kosten met een stand-by-replica.
Als uw secundaire replica wordt gebruikt alleen 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 gratis stand-by replica voor nadere informatie.
Volgende stappen
Zie voor overwegingen bij het ontwerpen van toepassingen Een toepassing ontwerpen voor herstel na noodgevallen in de cloud en strategieën voor herstel na noodgevallen van elastische pools.
Bekijk de richtlijnen voor herstel na noodgevallen van Azure SQL Database en controlelijst voor hoge beschikbaarheid van Azure SQL Database en controlelijst voor herstel na noodgevallen.