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 in het gevolg van onderbrekingen, met name voor de computerinfrastructuur. In de meeste gevallen verwerken SQL Database en SQL Managed Instance de verstorende gebeurtenissen die kunnen optreden in de cloudomgeving en blijven 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.
  • Aardbeving heeft een stroomstoring veroorzaakt en tijdelijk uitgeschakeld datacenter of andere catastrofale natuurrampgebeurtenissen.

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 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 gegevensintegriteit, een Azure-regio een storing heeft of dat uw toepassing onderhoud vereist.

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

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

  • Lokale hardware- of softwarefouten die invloed hebben op het databaseknooppunt, zoals een schijffout.
  • Gegevensbeschadiging of -verwijdering veroorzaakt meestal door een toepassingsfout of 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 beperken, bevat SQL Database een architectuur met hoge beschikbaarheid, die automatisch herstel van deze fouten garandeert met een SLA voor een beschikbaarheid van maximaal 99,995%.

Om uw bedrijf te beschermen tegen gegevensverlies, SQL Database en SQL Managed Instance automatisch wekelijks volledige databaseback-ups maken, differentiële databaseback-ups elke 12 uur en back-ups van transactielogboeken om de 5 - 10 minuten. De back-ups worden gedurende ten minste zeven dagen opgeslagen in RA-GRS-opslag voor alle servicelagen. Alle servicelagen, met uitzondering van basisondersteuning, configureerbare bewaarperiode voor back-ups voor herstel naar een bepaald tijdstip, tot 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.

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 het 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 minder dan 12 uur voor de herstelbewerkingen. Het kan langer duren om een zeer grote of zeer actieve database te herstellen. Zie de hersteltijd van de database voor meer informatie over hersteltijd.

Als de maximaal ondersteunde bewaarperiode voor back-up 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 aanvullende 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 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 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 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 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 herstellen na een storing als u geo-secundair hebt geconfigureerd met behulp van 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 failover zelf slechts een paar seconden duurt, duurt de service ten minste 1 uur om deze 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 kleine 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 krijgen in de maximale periode van recente gegevensupdates (tijdsinterval) die de toepassing kan verdragen 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. De volgende tabel vergelijkt RPO en RTO van elke hersteloptie. Groepen voor automatische failover vereenvoudigen de implementatie en het gebruik van geo-replicatie en voegen de aanvullende mogelijkheden toe, zoals beschreven in de volgende tabel:

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

Notitie

Handmatige databasefailover verwijst naar failover van één database naar de geo-gerepliceerde secundaire 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 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 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 uw toepassingsvereisten. Zie Voor een bespreking van ontwerpoverwegingen voor zelfstandige databases en voor elastische pools die gebruikmaken van deze functies voor bedrijfscontinuïteit , een toepassing ontwerpen voor herstel na noodgevallen in de cloud en strategieën voor herstel na noodgevallen van elastische pools.

De volgende secties bevatten een overzicht van de stappen voor het herstellen met behulp van databaseback-ups of actieve geo-replicatie. Zie Een database herstellen in SQL Database na een storing voor gedetailleerde stappen, waaronder planningsvereisten, 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, neemt het online brengen van uw toepassingen na een failover of het herstellen van een database extra tijd in beslag en is er waarschijnlijk ook een slechte combinatie nodig om problemen op te lossen.

Failover naar een secundaire database met geo-replicatie

Als u actieve geo-replicatie of groepen voor automatische failover gebruikt als herstelmechanisme, kunt u een beleid voor automatische failover configureren of handmatige niet-geplande failover gebruiken. Zodra de failover is gestart, wordt de secundaire de nieuwe primaire en gereed 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 datacentrum weer online komt, maken de oude primaries automatisch opnieuw verbinding met de nieuwe primaire en worden ze secundaire databases. Als u de primaire back-up 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 geo-herstel. Herstel vindt meestal binnen 12 uur plaats, met gegevensverlies van maximaal één uur, bepaald door het moment waarop 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. Houd er rekening mee dat geo-herstel alleen de database herstelt 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 voor gebruikers om verbinding te maken met of firewalls op databaseniveau te gebruiken om de juiste regels in te schakelen.
  • Zorg ervoor dat de juiste aanmeldingen en machtigingen op hoofddatabaseniveau 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, wordt de omleiding na een failover automatisch en transparant uitgevoerd op de toepassing.

Een toepassing upgraden met minimale uitvaltijd

Soms moet een toepassing offline worden gehaald vanwege gepland onderhoud, zoals een upgrade van een toepassing. In het beheer 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.

Volgende stappen

Zie Een toepassing ontwerpen voor herstel na noodgevallen en strategieën voor herstel na noodgevallen van elastische pools voor toepassingen voor individuele databases en elastische pools.