Overzicht van bedrijfscontinuïteit met Azure SQL Database & Azure SQL Managed Instance

VAN TOEPASSING OP: Azure SQL Database Azure SQL Managed Instance

Bedrijfscontinuïteit in Azure SQL Database en SQL Managed Instance verwijst naar de mechanismen, beleidsregels en procedures waarmee uw bedrijf kan blijven werken bij onderbrekingen, met name voor de computerinfrastructuur. In de meeste gevallen verwerken SQL Database en SQL Managed Instance de verstorende gebeurtenissen die in de cloudomgeving kunnen plaatsvinden, en blijven uw toepassingen en bedrijfsprocessen actief. Er zijn echter een aantal verstorende gebeurtenissen die niet automatisch kunnen worden SQL Database, zoals:

  • Gebruiker heeft per ongeluk een rij in een tabel verwijderd of bijgewerkt.
  • Kwaadwillende aanvallers zijn erin geslaagd om gegevens te verwijderen of een database te verwijderen.
  • Een aardbeving heeft een stroomstoring en een tijdelijk uitgeschakeld datacenter veroorzaakt.

In dit overzicht worden de mogelijkheden beschreven die SQL Database en SQL Managed Instance bieden voor bedrijfscontinuïteit en herstel na noodgevallen. Meer informatie over opties, aanbevelingen en zelfstudies voor het herstellen van verstorende gebeurtenissen die gegevensverlies kunnen veroorzaken of ervoor kunnen zorgen dat uw database en toepassing niet meer beschikbaar zijn. Meer informatie over wat u moet doen wanneer een fout van een gebruiker of toepassing van invloed is op de gegevensintegriteit, een Azure-regio een storing heeft of wanneer uw toepassing onderhoud vereist.

SQL Database-functies die u kunt gebruiken voor bedrijfscontinuïteit

Vanuit databaseperspectief zijn er vier belangrijke scenario's met mogelijke onderbrekingen:

  • Lokale hardware- of softwarefouten die invloed hebben op het database-knooppunt, zoals een schijffout.
  • Beschadiging of verwijdering van gegevens wordt meestal veroorzaakt door een toepassingsfout of menselijke fout. Dergelijke fouten zijn toepassingssyte specifiek en kunnen doorgaans niet worden gedetecteerd door de databaseservice.
  • Storing in datacenter, mogelijk veroorzaakt door een natuurramp. Dit scenario vereist een bepaalde mate van geo-redundantie met toepassings-failover naar een alternatief datacenter.
  • Upgrade- of onderhoudsfouten, onverwachte problemen die optreden tijdens gepland onderhoud of upgrades van de infrastructuur vereisen mogelijk snel terugdraaien naar een eerdere databasetoestand.

Om de lokale hardware- en softwarefouten te beperken, SQL Database een architectuur met hoge beschikbaarheid,die automatisch herstel van deze fouten garandeert met een SLA met een beschikbaarheid van maximaal 99,995%.

Om uw bedrijf te beschermen tegen gegevensverlies, maken SQL Database en SQL Managed Instance automatisch wekelijks volledige databaseback-ups, elke 12 uur differentiële databaseback-ups en elke 5 tot 10 minuten back-ups van transactielogboek. De back-ups worden voor alle servicelagen ten minste 7 dagen opgeslagen in RA-GRS-opslag. Alle servicelagen, behalve Basic Support configureerbare bewaarperiode voor back-ups voor herstel naar een bepaald tijdstip, maximaal 35 dagen.

SQL Database en SQL Managed Instance bieden ook verschillende functies voor bedrijfscontinuïteit die u kunt gebruiken om verschillende niet-geplande scenario's te beperken.

  • Tijdelijke tabellen maken het mogelijk rijversies te herstellen naar ieder gewenst tijdstip.
  • Met ingebouwde automatische back-ups en herstel naar een bepaald tijdstip kunt u de volledige database herstellen naar een bepaald tijdstip binnen de geconfigureerde bewaarperiode van maximaal 35 dagen.
  • U kunt een verwijderde database herstellen naar het punt waarop deze is verwijderd als de server niet is verwijderd.
  • Met langetermijnretentie van back-ups kunt u de back-ups maximaal tien jaar bewaren. Dit is in beperkte openbare preview voor SQL Managed Instance
  • Met actieve geo-replicatie kunt u leesbare replica's maken en handmatig een failover uitvoeren naar een replica in het geval van een storing in het datacenter of een toepassingsupgrade.
  • Met de groep voor automatische failover kan de toepassing automatisch worden hersteld in het geval van een storing in het datacenter.

Een database herstellen binnen dezelfde Azure-regio

U kunt automatische databaseback-ups gebruiken om een database te herstellen naar een bepaald tijdstip in het verleden. Op deze manier kunt u herstellen van beschadigingen van gegevens die worden veroorzaakt door menselijke fouten. Met herstel naar een bepaald tijdstip 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 herstellen minder dan 12 uur. Het kan langer duren om een zeer grote of zeer actieve database te herstellen. Zie databasehersteltijd voor meer informatie over hersteltijd.

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 beleid voor langetermijnretentie (LTR) te configureren voor de database(s). Zie Langetermijnretentie van back-ups voor meer informatie.

Geo-replicatie vergelijken met failovergroepen

Groepen voor automatische failover vereenvoudigen de implementatie en het gebruik van geo-replicatie en voegen de extra mogelijkheden toe, zoals beschreven in de volgende tabel:

Geo-replicatie Failovergroepen
Automatische failover Nee Ja
Gelijktijdige failover van meerdere databases Nee Ja
Gebruiker moet verbindingsreeks bijwerken na failover Ja Nee
Ondersteuning voor SQL Managed Instance Nee Ja
Kan zich in dezelfde regio bevinden als primaire replica Ja Nee
Meerdere replica's Ja Nee
Ondersteunt lezen-schalen Ja Ja

Een database herstellen op de bestaande server

Hoewel zeldzaam, kan een Azure-datacenter een storing hebben. Wanneer er een storing optreedt, veroorzaakt deze een bedrijfsonderbreking die mogelijk slechts een paar minuten maar ook enkele uren kan duren.

  • Een optie is om te wachten tot uw database weer online is wanneer de storing in het datacenter is voorbij. Dit werkt voor toepassingen waarvoor het niet erg is dat de database offline is. Bijvoorbeeld een ontwikkelingsproject of een gratis proefversie waaraan u niet voortdurend hoeft te werken. Wanneer een datacenter een storing heeft, weet u niet hoe lang de storing kan duren. Deze optie werkt dus alleen als u uw database een tijdje niet nodig hebt.
  • Een andere optie is om een database te herstellen op een server in elke Azure-regio met behulp van geografisch redundante databaseback-ups (geo-herstel). Geo-herstel maakt gebruik van een geografisch redundante back-up als bron en kan worden gebruikt om een database te herstellen, zelfs als de database of het datacenter niet toegankelijk is vanwege een storing.
  • Ten slotte kunt u snel herstellen na een storing als u geo-secundaire hebt geconfigureerd met actieve geo-replicatie of een groep voor automatische failover voor uw database of databases. Afhankelijk van uw keuze voor deze technologieën kunt u handmatige of automatische failover gebruiken. Hoewel de failover zelf slechts een paar seconden duurt, duurt het ten minste één uur om de failover te activeren. Dit is nodig om ervoor te zorgen dat de failover wordt gerechtvaardigd door de schaal van de storing. De failover kan ook leiden tot klein gegevensverlies vanwege de aard van asynchrone replicatie.

Tijdens het ontwikkelen van uw plan voor bedrijfscontinuïteit moet u weten wat de maximaal acceptabele tijd is voordat de toepassing volledig is hersteld na de verstorende gebeurtenis. De benodigde tijd voor het volledig herstellen van de toepassing staat bekend als Recovery Time Objective (RTO). U moet ook inzicht hebben in de maximale periode van recente gegevensupdates (tijdsinterval) die de toepassing kan verliezen bij het herstellen van een ongeplande verstorende gebeurtenis. Het potentiële gegevensverlies wordt RPO (Recovery Point Objective) genoemd.

Verschillende herstelmethoden bieden verschillende niveaus van RPO en RTO. U kunt een specifieke herstelmethode kiezen of een combinatie van methoden gebruiken om volledig toepassingsherstel te bereiken. In de volgende tabel worden RPO en RTO van elke hersteloptie vergeleken. Groepen voor automatische failover vereenvoudigen de implementatie en het gebruik van geo-replicatie en voegt de extra mogelijkheden toe, zoals beschreven in de volgende tabel.

Herstelmethode RTO RPO
Geo-herstel vanuit geo-gerepliceerde back-ups 12 uur 1 h
Automatische failover-groepen 1 h 5 s
Handmatige database-failover 30 s 5 s

Notitie

Handmatige database-failover verwijst naar failover van een individuele database naar de secundaire database met geo-replicatie met behulp van de niet-geplande modus. Zie de tabel eerder in dit artikel voor meer informatie over de RTO en RPO voor automatische failover.

Gebruik groepen voor automatische failover als uw toepassing aan een van deze criteria voldoet:

  • Is bedrijfskritiek.
  • Heeft een Service Level Agreement (SLA) die 12 uur of meer downtime niet toestaat.
  • Downtime kan leiden tot financiële aansprakelijkheid.
  • Heeft een hoge mate van gegevenswijziging en 1 uur gegevensverlies is niet acceptabel.
  • De extra kosten van actieve geo-replicatie zijn lager dan de mogelijke financiële verplichting en het bijbehorende bedrijfsverlies.

U kunt ervoor kiezen om een combinatie van databaseback-ups en actieve geo-replicatie te gebruiken, afhankelijk van de vereisten van uw toepassing. Zie Een toepassing ontwerpen voor herstel na nood aan de cloud en Strategieën voor herstel na nood aan elastische pools voor een bespreking van ontwerpoverwegingen voor stand-alone databases en elastische pools met behulp van deze functies voor bedrijfscontinuïteit.

De volgende secties bieden een overzicht van de stappen voor het herstellen met behulp van databaseback-ups of actieve geo-replicatie. Zie Een database in SQL Database herstellen na een storing voor gedetailleerde stappen, waaronder planningsvereisten, stappen na herstel en informatie over het simuleren van een storing om een noodhersteloefening uit te voeren.

Voorbereiden op een storing

Ongeacht de functie voor bedrijfscontinuïteit die u gebruikt, moet u:

  • Identificeer en bereid de doelserver voor, inclusief IP-firewallregels op serverniveau, aanmeldingen en machtigingen op hoofddatabaseniveau.
  • Bepalen hoe clients en clienttoepassingen naar de nieuwe server worden omgeleid.
  • Andere afhankelijkheden documenteren, zoals controle-instellingen en waarschuwingen.

Als u zich niet goed voorbereidt, kost het online brengen van uw toepassingen na een failover of databaseherstel extra tijd en is het waarschijnlijk ook nodig om problemen op te lossen op een moment van stress- een slechte combinatie.

Fail over naar een secundaire database met geo-replicatie

Als u actieve geo-replicatie of groepen voor automatische failover als herstelmechanisme gebruikt, kunt u een automatisch failoverbeleid configureren of handmatige niet-geplande failover gebruiken. Zodra de failover is gestart, wordt de secundaire replica de nieuwe primaire en is deze gereed om nieuwe transacties vast te registreren en te reageren op query's, met minimaal gegevensverlies voor de gegevens die nog niet zijn gerepliceerd. Zie Een toepassing ontwerpen voor herstel na noodherstel in de cloud voor meer informatie over het ontwerpen van het failoverproces.

Notitie

Wanneer het datacenter weer online komt, maken de oude primaries automatisch opnieuw verbinding met de nieuwe primaire database en worden ze secundaire databases. Als u de primaire regio weer naar de oorspronkelijke regio wilt verplaatsen, kunt u handmatig een geplande failover initiëren (failback).

Geo-herstel uitvoeren

Als u de automatische back-ups met geografisch redundante opslag gebruikt (standaard ingeschakeld), kunt u de database herstellen met behulp van geo-herstel. Herstel vindt doorgaans binnen 12 uur plaats, met gegevensverlies van maximaal één uur, bepaald door het moment waarop de laatste logboekback-up is gemaakt en gerepliceerd. Totdat het herstellen is voltooid, kan de database geen transacties registreren en niet reageren op query's. Houd er rekening mee dat met geo-herstel alleen de database wordt hersteld naar het laatst beschikbare tijdstip.

Notitie

Als het datacenter weer online komt voordat u uw toepassing overschakelt naar de herstelde database, kunt u het herstel annuleren.

Taken na failover/hersteltaken uitvoeren

Na herstel via een van beide herstelmechanismen moet u de volgende aanvullende taken uitvoeren voordat uw gebruikers en toepassingen opnieuw actief zijn:

  • Clients en clienttoepassingen omleiden naar de nieuwe server en de herstelde database.
  • Zorg ervoor dat de juiste IP-firewallregels op serverniveau zijn ingesteld voor gebruikers om verbinding te maken of firewalls op databaseniveau te gebruiken om de juiste regels in te stellen.
  • Zorg ervoor dat de juiste aanmeldingen en machtigingen op hoofddatabaseniveau zijn gebruikt (of gebruik ingesloten gebruikers).
  • Configureer de controle, waar van toepassing.
  • Configureer waar nodig waarschuwingen.

Notitie

Als u een failovergroep gebruikt en verbinding maakt met de databases met behulp van de listener voor lezen/schrijven, vindt de omleiding na een failover automatisch en transparant voor de toepassing uit.

Een toepassing upgraden met minimale uitvaltijd

Soms moet een toepassing offline worden gehaald vanwege gepland onderhoud, zoals een toepassingsupgrade. Toepassingsupgrades beheren beschrijft hoe u actieve geo-replicatie gebruikt om rolling upgrades van uw cloudtoepassing mogelijk te maken om downtime tijdens upgrades te minimaliseren en een herstelpad te bieden als er iets misgaat.

Volgende stappen

Zie Een toepassing ontwerpen voor herstel na noodherstel in de cloud en Strategieën voor herstel na noodherstel voor elastische pools voor een bespreking van overwegingen voor het ontwerp van toepassingen voor individuele databases en elastische pools.