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 die uw bedrijf in staat stellen om te blijven werken met het oog op onderbrekingen, met name in de computerinfrastructuur. In de meeste gevallen verwerken SQL Database en SQL Managed Instance de verstorende gebeurtenissen die zich in de cloudomgeving kunnen voordoen en houden uw toepassingen en bedrijfsprocessen actief. Er zijn echter enkele verstorende gebeurtenissen die niet automatisch kunnen worden verwerkt door 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 veroorzaakt en het datacentrum tijdelijk uitgeschakeld of een andere catastrofale natuurramp.

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 ertoe kunnen leiden dat uw database en toepassing niet meer beschikbaar zijn. Meer informatie over wat u moet doen wanneer een gebruikers- of toepassingsfout van invloed is op de gegevensintegriteit, een Azure-regio een storing heeft of uw toepassing onderhoud vereist.

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

Vanuit het perspectief van de database zijn er vier belangrijke scenario's voor mogelijke onderbrekingen:

  • Lokale hardware- of softwarefouten die invloed hebben op het databaseknooppunt, zoals een schijffout.
  • Gegevensbeschadiging of verwijdering wordt meestal veroorzaakt door een toepassingsfout of een menselijke fout. Dergelijke fouten zijn toepassingsspecifiek 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 een snel terugdraaien naar een eerdere databasetoestand.

Om de lokale hardware- en softwarefouten te verhelpen, bevat SQL Database een architectuur voor 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, 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 transactielogboeken maken. De back-ups worden voor alle servicelagen ten minste zeven dagen opgeslagen in RA-GRS-opslag. Alle servicelagen behalve Basic ondersteunen configureerbare bewaarperiode voor back-ups voor herstel naar een bepaald tijdstip, maximaal 35 dagen.

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

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 kunt u op dezelfde server een nieuwe database maken die de status van de gegevens vóór de beschadigde gebeurtenis vertegenwoordigt. Voor de meeste databases duren de herstelbewerkingen minder dan 12 uur. Het kan langer duren om een zeer grote of zeer actieve database te herstellen. Zie Hersteltijd van database voor meer informatie over hersteltijd.

Als de maximaal ondersteunde bewaarperiode voor back-ups voor herstel naar een bepaald tijdstip (PITR) niet voldoende is voor uw toepassing, kunt u deze uitbreiden door een beleid voor langetermijnretentie (LTR) voor de database(s) te configureren. 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 naar de bestaande server

Hoewel dit zeldzaam is, 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 totdat uw database weer online komt wanneer de storing in het datacenter voorbij is. 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 datacentrum 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 elke server in een 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 een storing herstellen als u geo-secundair hebt geconfigureerd met actieve geo-replicatie of een groep voor automatische failover voor uw database of databases. Afhankelijk van uw keuze van deze technologieën kunt u handmatige of automatische failover gebruiken. Hoewel failover zelf slechts een paar seconden duurt, duurt het ten minste 1 uur voordat de service deze activeert. 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 tijd die nodig is om de toepassing volledig te herstellen, wordt RTO (Recovery Time Objective) genoemd. U moet ook inzicht hebben in de maximale periode van recente gegevensupdates (tijdsinterval) die de toepassing kan laten verliezen bij het herstellen van een niet-geplande 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 voegen de extra mogelijkheden toe, zoals beschreven in de volgende tabel:

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

Notitie

Handmatige databasefailover verwijst naar failover van één database naar de secundaire geo-gerepliceerde database 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 geen uitvaltijd van 12 uur of meer 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 noodgevallen in de cloud en Strategieën voor herstel na noodgevallen voor elastische pools voor een bespreking van ontwerpoverwegingen voor zelfstandige databases en elastische pools die gebruikmaken 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 herstellen in SQL Database van een storing voor gedetailleerde stappen, waaronder planningsvereisten, stappen na herstel en informatie over het simuleren van een storing om een noodherstelanalyse 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 master machtigingen op databaseniveau.
  • 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 een databaseherstel meer tijd en moet u waarschijnlijk ook problemen oplossen op een moment van stress- een slechte combinatie.

Failover naar een geo-gerepliceerde secundaire database

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

Notitie

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

Geo-herstel uitvoeren

Als u de geautomatiseerde back-ups gebruikt met geografisch redundante opslag (standaard ingeschakeld), kunt u de database herstellen met behulp van geo-herstel. Herstel vindt meestal plaats binnen 12 uur, met gegevensverlies van maximaal één uur, afhankelijk van wanneer de laatste back-up van het logboek is gemaakt en gerepliceerd. Totdat het herstellen is voltooid, kan de database geen transacties registreren en niet reageren op query's. Met geo-herstel wordt de database alleen 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 herstelde database.
  • Zorg ervoor dat de juiste IP-firewallregels op serverniveau zijn ingesteld zodat gebruikers verbinding kunnen maken met of firewalls op databaseniveau kunnen gebruiken om de juiste regels in te schakelen.
  • Zorg ervoor dat de juiste aanmeldingen en master machtigingen op databaseniveau aanwezig zijn (of gebruik ingesloten gebruikers).
  • Configureer controles, indien van toepassing.
  • Configureer waarschuwingen, indien van toepassing.

Notitie

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

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 noodgevallen in de cloud en Strategieën voor herstel na noodgevallen voor elastische pools voor een bespreking van overwegingen bij het ontwerpen van toepassingen voor individuele databases en elastische pools.