Delen via


Overzicht van bedrijfscontinuïteit met Azure SQL Managed Instance

van toepassing op:Azure SQL Managed Instance

Dit artikel bevat een overzicht van de mogelijkheden voor bedrijfscontinuïteit en herstel na noodgevallen van Azure SQL Managed Instance, waarin de opties en aanbevelingen worden beschreven voor het herstellen van verstorende gebeurtenissen die kunnen leiden tot gegevensverlies of waardoor uw exemplaar 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 Managed Instance verwijst naar de mechanismen, beleidsregels en procedures waarmee uw bedrijf kan blijven werken in het geval van onderbrekingen door beschikbaarheid, hoge beschikbaarheid en herstel na noodgevallen te bieden.

In de meeste gevallen verwerkt SQL Managed Instance 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.
  • Door een catastrofale natuurramp wordt een datacenter, beschikbaarheidszone of regio platgelegd.
  • Zeldzame datacenter-, beschikbaarheidszone- of regiobrede storing veroorzaakt door een configuratiewijziging, softwarefout of hardwareonderdeelfout.

Beschikbaarheid

Azure SQL Managed Instance 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 Managed Instance-service beschikbaarheid als een standaardfunctie met een toonaangevende SLA voor beschikbaarheid van 99,99%.

Hoge beschikbaarheid

Als u hoge beschikbaarheid in de Azure-cloudomgeving wilt bereiken, schakelt u zoneredundantie in zodat het exemplaar gebruikmaakt van beschikbaarheidszones om tolerantie voor zonefouten te garanderen. 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 het exemplaar bestand tegen zonegebonden hardware- en softwarefouten en is het herstel transparant voor toepassingen. Wanneer hoge beschikbaarheid is ingeschakeld, kan de Azure SQL Managed Instance-service een SLA met een hogere beschikbaarheid van 99,99%bieden.

Noodherstel

Als u een hogere beschikbaarheid en redundantie in verschillende regio's wilt bereiken, kunt u mogelijkheden voor herstel na noodgevallen inschakelen om het exemplaar snel te herstellen na een catastrofale regionale storing. Opties voor herstel na noodgevallen met Azure SQL Managed Instance zijn:

  • Failovergroepen schakelen voortdurende synchronisatie in tussen een primaire en secundaire instantie. Failovergroepen bieden lees- en schrijf- en alleen-lezen-listener-eindpunten die ongewijzigd blijven, zodat het bijwerken van toepassingsverbindingsreeksen na een failover niet nodig is.
  • Geo-herstel stelt u in staat om te herstellen van een regionale storing door, wanneer u geen toegang heeft tot uw database in de primaire regio, gebruik te maken van geo-gerepliceerde back-ups. U kunt een nieuwe database creëren op een bestaande instantie in een willekeurige Azure-regio.

Functies die bedrijfscontinuïteit bieden

Er zijn bijvoorbeeld vier belangrijke scenario's voor potentiële onderbrekingen. De volgende tabel bevat functies voor bedrijfscontinuïteit van SQL Managed Instance 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 Managed Instance een beschikbaarheidsarchitectuur, waardoor automatisch herstel van deze fouten met maximaal 99,99% beschikbaarheids-SLA wordt gegarandeerd.
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 service. Om uw bedrijf te beschermen tegen gegevensverlies, maakt SQL Managed Instance elke 12 of 24 uur automatisch volledige databaseback-ups, differentiële databaseback-ups en elke 5 tot 10 minuten back-ups van transactielogboeken. Back-ups worden standaard gedurende zeven dagen opgeslagen in geografisch redundante opslag en ondersteunen een configureerbare bewaarperiode voor back-ups voor herstel naar een bepaald tijdstip van maximaal 35 dagen. U kunt een verwijderde database herstellen naar het punt waarop deze is verwijderd als het exemplaar niet is verwijderd of als u langetermijnretentie hebt geconfigureerd.
Zeldzame storingen in datacenters of beschikbaarheidszones, mogelijk veroorzaakt door een natuurramp, configuratiewijziging, softwarefout of storing van hardwareonderdelen. Schakel zoneredundantie in voor de SQL Managed Instance 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 het beheerde exemplaar bestand is tegen zonefouten met maximaal 99,99% SLA voor hoge beschikbaarheid.
Zeldzame regiostoring die van invloed is 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 volgende opties:
- Continue gegevenssynchronisatie met failovergroepen naar replica's in een secundaire regio die wordt gebruikt voor failover.
- Back-upopslagredundantie instellen op geografisch redundante opslag 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 (uitvaltijd) RPO (gegevensverlies)
Hoge beschikbaarheid
(zoneredundantie gebruiken)
Doorgaans minder dan 30 seconden 0
Herstel na noodgevallen
(failovergroepen gebruiken met failoverbeleid beheerd door de klant)
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)
12 uur 1 uur

Controlelijsten voor bedrijfscontinuïteit

Raadpleeg het volgende voor prescriptieve aanbevelingen om de beschikbaarheid te maximaliseren en een hogere bedrijfscontinuïteit te bereiken:

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 naar hetzelfde exemplaar, of een ander exemplaar, dat de status van gegevens vertegenwoordigt vóór de beschadigde gebeurtenis. De herstelbewerking is een datagrootte-operatie die ook afhankelijk is van de huidige werklast van de doelinstantie. Het kan langer duren om een zeer grote of zeer actieve database te herstellen. Zie databasehersteltijdvoor 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 langetermijnretentiebeleid (LTR) voor de database(s) te configureren. Zie voor meer informatie retentie van back-ups op de lange termijn.

Een database herstellen naar een bestaand exemplaar

Hoewel dit zelden voorkomt, kan een Azure-datacenter een storing hebben. Wanneer er een storing optreedt, veroorzaakt dit een bedrijfsonderbreking die slechts enkele minuten kan duren of uren kan duren.

  • Een optie is om te wachten totdat uw exemplaar weer online komt wanneer de storing in het datacenter voorbij is. Dit werkt voor toepassingen die hun database offline kunnen hebben. 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 enige tijd niet nodig hebt.
  • Als u geografisch redundante opslag (GRS) of geografisch zone-redundante opslag (GZRS) gebruikt, is een andere optie om een database te herstellen naar een beheerd SQL-exemplaar 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 naar het laatst beschikbare tijdstip, zelfs als de database of het datacenter niet toegankelijk is vanwege een storing. De beschikbare back-up vindt u in de gekoppelde regio.
  • Ten slotte kunt u snel herstellen na een storing als u een geo-secundaire hebt geconfigureerd met behulp van een failovergroep voor uw instantie, met behulp van klant (aanbevolen) of door Microsoft beheerd failover. Hoewel de failover zelf slechts een paar seconden duurt, duurt het minstens 1 uur voordat de service een door Microsoft beheerde geo-failover activeert, indien geconfigureerd. Dit is nodig om ervoor te zorgen dat de failover wordt gerechtvaardigd door de schaal van de storing. De failover kan ook leiden tot het verlies van onlangs gewijzigde gegevens vanwege de aard van asynchrone replicatie tussen de gekoppelde regio's.

Wanneer u uw bedrijfscontinuïteitsplan ontwikkelt, moet u weten wat de maximale acceptabele tijd is voordat de toepassing volledig herstelt 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 krijgen in 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.

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.

Gebruik failovergroepen als uw toepassing voldoet aan een van deze criteria:

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

U kunt ervoor kiezen om een combinatie van databaseback-ups en failovergroepen te gebruiken, afhankelijk van uw toepassingsvereisten.

De volgende secties bevatten een overzicht van de stappen voor het herstellen met behulp van databaseback-ups of failovergroepen.

Voorbereiden op een storing

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

  • Identificeer en bereid het doelexemplaar voor, inclusief firewallregels voor netwerk-IP, aanmeldingen en machtigingen op databaseniveau zoals master.
  • Bepaal hoe je clients en clienttoepassingen kunt omleiden naar de nieuwe instantie.
  • Andere afhankelijkheden documenteren, zoals controle-instellingen en waarschuwingen

Als u zich niet goed voorbereidt, neemt het online brengen van uw toepassingen na een failover of een databaseherstel extra tijd in beslag en vereist waarschijnlijk ook probleemoplossing op een moment van stress: een slechte combinatie.

Failover uitvoeren naar een geo-gerepliceerd secundair exemplaar

Als u failovergroepen als herstelmechanisme gebruikt, kunt u een beleid voor automatische failover configureren. Nadat de failover is gestart, wordt het secundaire exemplaar de nieuwe primaire instantie, klaar om nieuwe transacties vast te leggen en te reageren op query's, met minimaal gegevensverlies voor de gegevens die nog niet zijn gerepliceerd.

Notitie

Wanneer het datacenter weer online komt, wordt de oude primaire automatisch opnieuw verbonden met de nieuwe primaire om het secundaire exemplaar te worden. Als u de primaire terug wilt verplaatsen naar de oorspronkelijke regio, kunt u een geplande failover handmatig initiëren (failback).

Geo-herstel uitvoeren

Als u geautomatiseerde back-ups gebruikt met Geografisch Redundante Opslag (de standaardopslagoptie wanneer u uw instantie maakt), kunt u de database herstellen met geo-herstel. Herstel vindt meestal plaats binnen 12 uur, met gegevensverlies van maximaal één uur, bepaald door het moment waarop de laatste back-up van het logboek is gemaakt en gerepliceerd. Totdat het herstel is voltooid, kan de database geen transacties registreren of 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/herstel uitvoeren

Na herstel via een van de herstelmechanismen moet u de volgende extra taken uitvoeren voordat uw gebruikers en toepassingen weer operationeel zijn:

  • Clients en clienttoepassingen omleiden naar het nieuwe exemplaar en de herstelde database.
  • Zorg ervoor dat de juiste netwerk-IP-firewallregels zijn ingesteld om gebruikers verbinding te laten maken.
  • Zorg ervoor dat de juiste logins en master-machtigingen op databaseniveau aanwezig zijn, of gebruik ingesloten gebruikers.
  • Stel de audit in, waar nodig.
  • Configureer waarschuwingen, indien van toepassing.

Notitie

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

Licentievrije DR-replica's

U kunt besparen op licentiekosten door een secundair Azure SQL Managed Instance te configureren voor herstel na noodgevallen (DR). Dit voordeel is beschikbaar als u een failovergroep gebruikt tussen twee met SQL beheerde exemplaren of als u een hybride koppeling tussen SQL Server en Azure SQL Managed Instance hebt geconfigureerd. Zolang het secundaire exemplaar geen lees- of schrijfbelastingen heeft en alleen een passieve DR-standby is, worden er geen kosten in rekening gebracht voor de vCore-licenties die door het secundaire exemplaar worden gebruikt.

Wanneer u een secundair exemplaar aanwijst voor alleen herstel na noodgevallen en er geen lees- of schrijfworkloads worden uitgevoerd op het exemplaar, biedt Microsoft u het aantal vCores waarvoor een licentie is verleend aan het primaire exemplaar zonder extra kosten onder het voordeel van failoverrechten. U wordt nog steeds gefactureerd voor de berekening en opslag die door het secundaire exemplaar wordt gebruikt. Zie de licentievoorwaarden voor SQL Server online in het gedeelte 'SQL Server - Failover-rechten' voor nauwkeurige voorwaarden van het voordeel van hybride failoverrechten.

De naam van het voordeel is afhankelijk van uw scenario:

  • hybride failoverrechten voor een passieve replica: wanneer u een koppeling tussen SQL Server en Azure SQL Managed Instance configureert, kunt u de hybride failoverrechten voordeel gebruiken om te besparen op vCore-licentiekosten voor de passieve secundaire replica.
  • Failover-rechten voor een stand-byreplica: wanneer u een failovergroep tussen twee beheerde exemplaren configureert, kunt u het Failover-rechten voordeel gebruiken om te besparen op vCore-licentiekosten voor de stand-byreplica.

In het volgende diagram ziet u het voordeel voor elk scenario:

Diagram dat de failoverrechten voor Azure SQL Managed Instance vergelijkt.

Volgende stappen

Zie Automatische back-upsen failovergroepenvoor meer informatie over functies voor bedrijfscontinuïteit. Zie voor herstel na noodgevallen een database herstellen en zoneredundantie inschakelen voor Azure SQL Managed Instance.