Delen via

Betrouwbaarheid in Azure SQL Managed Instance

Azure SQL Managed Instance is een volledig beheerde PaaS-database-engine (Platform as a Service). Het biedt bijna 100% functiecompatibiliteit met SQL Server. Azure SQL Managed Instance verwerkt de meeste databasebeheerfuncties, zoals upgraden, patchen, back-ups en bewaking zonder tussenkomst van de gebruiker. Het wordt uitgevoerd op de nieuwste stabiele versie van de SQL Server-database-engine en een gepatcht besturingssysteem met ingebouwde hoge beschikbaarheid.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u Azure SQL Managed Instance tolerant maakt voor verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone en regiostoringen. Ook wordt beschreven hoe u back-ups kunt gebruiken om te herstellen van andere soorten problemen, hoe u serviceonderhoud kunt afhandelen en belangrijke informatie over de Service Level Agreement (SLA) van Azure SQL Managed Instance kunt bekijken.

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Houd rekening met de volgende aanbevelingen voor de meeste productie-implementaties van SQL Managed Instance:

Overzicht van betrouwbaarheidsarchitectuur

Sql Managed Instances voor algemeen gebruik worden uitgevoerd op één knooppunt dat door Azure Service Fabric wordt beheerd. Wanneer de database-engine of het besturingssysteem wordt bijgewerkt of er een fout wordt gedetecteerd, werkt SQL Managed Instance met Service Fabric om het staatloze database-engineproces te verplaatsen naar een ander staatloos rekenknooppunt met voldoende vrije capaciteit. Databasebestanden worden opgeslagen in Azure Blob Storage, met ingebouwde redundantiefuncties. Gegevens- en logboekbestanden worden losgekoppeld van het oorspronkelijke rekenknooppunt en gekoppeld aan het zojuist geïnitialiseerde database-engineproces.

Bedrijfskritieke SQL-beheerde exemplaren gebruiken meerdere replica's in een cluster. Het cluster bevat twee typen replica's:

  • Eén primaire replica die kan worden geopend voor lees- en schrijfwerkbelastingen van klanten

  • Maximaal vijf secundaire replica's (berekening en opslag) die kopieën van gegevens bevatten

De primaire replica pusht voortdurend en sequentieel wijzigingen naar de secundaire replica's, wat ervoor zorgt dat gegevens op een voldoende aantal secundaire replica's worden bewaard voordat elke transactie wordt doorgevoerd. Dit proces garandeert dat als de primaire replica of een leesbare secundaire replica niet meer beschikbaar is, een volledig gesynchroniseerde replica altijd beschikbaar is voor failover.

Sql Managed Instance en Service Fabric initiëren failover tussen replica's. Nadat een secundaire replica de nieuwe primaire replica wordt, wordt er een andere secundaire replica gemaakt om ervoor te zorgen dat het cluster voldoende replica's heeft om quorum te behouden. Nadat de failover is voltooid, worden Azure SQL-verbindingen automatisch omgeleid naar de nieuwe primaire replica of de leesbare secundaire replica, op basis van de verbindingsreeks.

Redundancy

SQL Managed Instance bereikt standaard redundantie door rekenknooppunten en gegevens over één datacenter in de primaire regio te spreiden. Deze aanpak beschermt uw gegevens tijdens de volgende verwachte en onverwachte downtime:

  • Door de klant geïnitieerde beheerbewerkingen die resulteren in een korte downtime

  • Serviceonderhoudsbewerkingen

  • Kleinschalige netwerk- of stroomstoringen

  • Problemen en datacentrumstoringen die betrekking hebben op de volgende onderdelen:

    • Het rek waarop de machines die uw service aandrijven, draaien.

    • De fysieke machine die als host fungeert voor de virtuele machine (VM) waarop de SQL Database Engine wordt uitgevoerd.

    • De VM waarop de SQL Database Engine wordt uitgevoerd

  • Problemen met de SQL Database Engine

  • Mogelijke niet-geplande gelokaliseerde storingen

Zie Beschikbaarheid via lokale en zoneredundantie voor meer informatie over hoe SQL Managed Instance redundantie biedt.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

SQL Managed Instance verwerkt automatisch kritieke onderhoudstaken, zoals patches, back-ups en upgrades van Windows en SQL Database Engine. Het verwerkt ook niet-geplande gebeurtenissen, zoals onderliggende hardware, software of netwerkfouten. SQL Managed Instance kan snel worden hersteld, zelfs in de meest kritieke omstandigheden, waardoor uw gegevens altijd beschikbaar zijn. De meeste gebruikers merken niet dat upgrades continu worden uitgevoerd.

Wanneer een exemplaar wordt gepatcht of een failover optreedt, heeft de downtime een minimaal effect als u herhalingslogica in uw toepassing gebruikt. U kunt de tolerantie van uw toepassing testen op tijdelijke fouten.

Tolerantie voor fouten in beschikbaarheidszones

Opmerking

Zoneredundantie is momenteel niet beschikbaar voor de servicelaag Algemeen gebruik van de volgende generatie.

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Wanneer u een zone-redundante configuratie inschakelt, kunt u ervoor zorgen dat uw beheerde SQL-exemplaar bestand is tegen een grote set fouten, inclusief catastrofale datacenterstoringen, zonder wijzigingen in de toepassingslogica.

SQL Managed Instance bereikt zoneredundantie door staatloze rekenknooppunten in verschillende beschikbaarheidszones te plaatsen. Het is afhankelijk van stateful ZRS die is gekoppeld aan het knooppunt dat momenteel het actieve SQL Database Engine-proces bevat. Als er een storing optreedt, wordt het SQL Database Engine-proces actief op een van de staatloze rekenknooppunten, die vervolgens toegang heeft tot de gegevens in de stateful opslag.

MET SQL Managed Instance wordt zoneredundantie bereikt door replica's van uw met SQL beheerde exemplaar in meerdere beschikbaarheidszones te plaatsen. Als u een single point of failure wilt voorkomen, wordt de besturingsring ook gedupliceerd in meerdere zones. Het control plane-verkeer wordt geleid naar een load balancer die ook over beschikbaarheidszones wordt gebruikt. Azure Traffic Manager regelt de verkeersroutering van het besturingsvlak naar de load balancer.

Requirements

  • Regioondersteuning: Zoneredundantie voor SQL Managed Instance wordt ondersteund in bepaalde regio's. Zie Ondersteunde regio's voor meer informatie.

  • Redundantie van back-upopslag: Als u zoneredundantie wilt inschakelen voor uw met SQL beheerde exemplaar, stelt u de redundantie van back-upopslag in op ZRS of geografisch zone-redundante opslag (GZRS).

Kosten

Wanneer u zoneredundantie inschakelt, zijn er extra kosten verbonden aan uw met SQL beheerde exemplaar en voor zone-redundante back-ups. Ga voor meer informatie naar Prijzen.

U kunt geld besparen door rekenresources te gebruiken tegen een gereduceerd tarief voor een bepaalde periode, waaronder zone-redundante instanties in de servicelaag Bedrijfskritiek. Zie Reserveringen voor SQL Managed Instance voor meer informatie.

Ondersteuning voor beschikbaarheidszones configureren

In deze sectie wordt uitgelegd hoe u ondersteuning voor beschikbaarheidszones configureert voor uw met SQL beheerde exemplaren:

  • Zoneredundantie inschakelen: Zie Zoneredundantie configureren voor nieuwe en bestaande exemplaren voor meer informatie over het configureren van zoneredundantie.

    Alle schaalbewerkingen voor SQL Managed Instance, inclusief het inschakelen van zoneredundantie, zijn onlinebewerkingen en vereisen minimale tot geen downtime. Zie Duur van beheerbewerkingen voor meer informatie.

  • Zoneredundantie uitschakelen: U kunt zoneredundantie uitschakelen volgens dezelfde stappen om zoneredundantie in te schakelen. Dit proces is een onlinebewerking die vergelijkbaar is met een reguliere upgrade van de servicelaagdoelstelling. Aan het einde van het proces wordt het exemplaar gemigreerd van zone-redundante infrastructuur naar infrastructuur met één zone.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer uw met SQL beheerde exemplaar is geconfigureerd als zone-redundant en alle beschikbaarheidszones operationeel zijn:

  • Verkeersroutering tussen zones: Tijdens normale bewerkingen worden aanvragen doorgestuurd naar het knooppunt waarop uw SQL Managed Instance-rekenlaag wordt uitgevoerd.

  • Gegevensreplicatie tussen zones: Databasebestanden worden opgeslagen in Azure Storage met behulp van ZRS, die is gekoppeld aan het knooppunt dat momenteel het actieve SQL Database Engine-proces bevat.

    Schrijfbewerkingen zijn synchroon en worden pas als voltooid beschouwd als de gegevens zijn gerepliceerd in alle beschikbaarheidszones. Deze synchrone replicatie zorgt voor sterke consistentie en nul gegevensverlies tijdens zonefouten. Dit kan echter leiden tot iets hogere schrijflatentie in vergelijking met lokaal redundante opslag.

  • Verkeersroutering tussen zones: Tijdens normale bewerkingen worden aanvragen doorgestuurd naar de primaire replica van uw met SQL beheerde exemplaar.

  • Gegevensreplicatie tussen zones: De primaire replica pusht voortdurend en sequentieel wijzigingen naar de secundaire replica's in verschillende beschikbaarheidszones. Dit proces zorgt ervoor dat gegevens worden bewaard op een voldoende aantal secundaire replica's voordat elke transactie wordt doorgevoerd. Deze replica's bevinden zich in verschillende beschikbaarheidszones. Dit proces garandeert dat, als de primaire replica of een leesbare secundaire replica om welke reden dan ook niet beschikbaar is, een volledig gesynchroniseerde replica altijd beschikbaar is voor failover.

    Omdat zone-redundante exemplaren replica's hebben in verschillende datacenters met enige afstand ertussen, kan de verhoogde netwerklatentie de doorvoertijd van de transactie verhogen. Deze toename kan van invloed zijn op de prestaties van sommige OLTP-workloads (Online Transaction Processing). De meeste toepassingen zijn niet gevoelig voor deze extra latentie.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer uw met SQL beheerde exemplaar is geconfigureerd voor zone-redundant en een of meer beschikbaarheidszones niet beschikbaar zijn:

  • Detectie en reactie: SQL Managed Instance is verantwoordelijk voor het detecteren en reageren op een fout in een beschikbaarheidszone. U hoeft niets te doen om een zonefailover te starten.
  • Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Resource Health echter gebruiken om te controleren op de status van een afzonderlijke resource en u kunt Resource Health-waarschuwingen instellen om u op de hoogte te stellen van problemen. U kunt Azure Service Health ook gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.
  • Actieve aanvragen: Wanneer een beschikbaarheidszone niet beschikbaar is, worden alle aanvragen die in de defecte beschikbaarheidszone worden verwerkt, beëindigd en moeten ze opnieuw worden geprobeerd. Als u uw toepassingen tolerant wilt maken voor dit soort problemen, raadpleegt u Richtlijnen voor tolerantie voor tijdelijke fouten .

  • Verkeer omleiden: SQL Managed Instance werkt met Service Fabric om de database-engine te verplaatsen naar een geschikt staatloos rekenknooppunt dat zich in een andere beschikbaarheidszone bevindt en voldoende vrije capaciteit heeft. Nadat de failover is voltooid, worden nieuwe verbindingen automatisch omgeleid naar het nieuwe primaire rekenknooppunt.

    Een zware workload kan prestatievermindering ondervinden tijdens de overgang van het ene rekenknooppunt naar het andere rekenknooppunt, omdat het nieuwe database-engineproces begint met een koude cache.

  • Verkeer omleiden: SQL Managed Instance werkt met Service Fabric om een geschikte replica in een andere beschikbaarheidszone te selecteren om de primaire replica te worden. Nadat een secundaire replica de nieuwe primaire replica wordt, wordt er een andere secundaire replica gemaakt om ervoor te zorgen dat het cluster voldoende replica's heeft om quorum te behouden. Nadat de failover is voltooid, worden nieuwe verbindingen automatisch omgeleid naar de nieuwe primaire replica of de leesbare secundaire replica op basis van de verbindingsreeks.

  • Verwachte downtime: Er kan een kleine hoeveelheid downtime optreden tijdens een failover van een beschikbaarheidszone. De downtime is doorgaans minder dan 30 seconden, wat uw toepassing moet tolereren als deze de richtlijnen voor tolerantie voor tijdelijke fouten volgt.

  • Verwachte gegevensverlies: Er wordt geen gegevensverlies verwacht voor vastgelegde transacties tijdens een failover van een beschikbaarheidszone. Transacties die worden uitgevoerd, moeten opnieuw worden geprobeerd.

Zoneherstel

Wanneer de beschikbaarheidszone wordt hersteld, werkt SQL Managed Instance met Service Fabric om bewerkingen in de herstelde zone te herstellen. Er is geen tussenkomst van de klant vereist.

Testen op zonefouten

Het SQL Managed Instance-platform beheert verkeersroutering, failover en failback voor zone-redundante exemplaren. Omdat deze functie volledig wordt beheerd, hoeft u geen processen voor fouten in de beschikbaarheidszone te initiëren of valideren. U kunt de verwerking van fouten in uw toepassing echter valideren.

Tolerantie voor storingen in de hele regio

Een afzonderlijk met SQL beheerd exemplaar wordt binnen één regio geïmplementeerd. U kunt echter een secundair met SQL beheerd exemplaar implementeren in een afzonderlijke Azure-regio en een failovergroep configureren.

Failovergroepen

Failovergroepen geo-repliceren automatisch uw gegevens en kunnen, op basis van het failoverbeleid, automatisch of handmatig overschakelen bij een regionale storing.

In deze sectie vindt u een overzicht van belangrijke informatie over failovergroepen, maar het is belangrijk dat u het overzicht van failovergroepen en aanbevolen procedures bekijkt voor meer informatie over hoe ze werken en hoe u deze configureert.

Failoverbeleid

Wanneer u een failovergroep maakt, selecteert u het failoverbeleid, waarmee wordt aangegeven wie verantwoordelijk is voor het detecteren van een storing en het uitvoeren van een failover. U kunt twee typen failoverbeleid configureren:

  • Door de klant beheerde failover (aanbevolen): Wanneer u een door de klant beheerd failoverbeleid gebruikt, kunt u bepalen of een failover moet worden uitgevoerd, wat geen gegevensverlies met zich meebrengt of een geforceerde failover, waardoor gegevensverlies kan optreden. Geforceerde failover wordt gebruikt als herstelmethode tijdens storingen wanneer het primaire exemplaar niet kan worden geopend.

  • Door Microsoft beheerde failover: Door Microsoft beheerde failover wordt alleen gebruikt in uitzonderlijke situaties om een geforceerde failover te activeren.

Belangrijk

Gebruik door de klant beheerde failoveropties voor het ontwikkelen, testen en implementeren van uw DR-plannen. Vertrouw niet op door Microsoft beheerde failover, die alleen in extreme omstandigheden kan worden gebruikt. Een door Microsoft beheerde failover wordt waarschijnlijk geïnitieerd voor een hele regio. Het kan niet worden gestart voor afzonderlijke failovergroepen, door SQL beheerde exemplaren, abonnementen of klanten. Failover kan zich op verschillende momenten voordoen voor verschillende Azure-services. We raden u aan om door de klant beheerde failover te gebruiken.

Ondersteuning voor regio

U kunt elke Azure-regio selecteren voor de met SQL beheerde exemplaren binnen de failovergroep. Vanwege de hoge latentie van wide area networks maakt geo-replicatie gebruik van een asynchroon replicatiemechanisme. Als u netwerkvertragingen wilt verminderen, selecteert u regio's met verbindingen met lage latentie. Zie Azure netwerk round-trip latentiestatistieken voor meer informatie over latency tussen Azure-regio's.

Kosten

Wanneer u meerdere met SQL beheerde exemplaren in verschillende regio's maakt, wordt u gefactureerd voor elk beheerd SQL-exemplaar.

Als uw secundaire exemplaar echter geen leesworkloads of toepassingen heeft die eraan zijn gekoppeld, kunt u besparen op licentiekosten door de replica aan te wijzen als een stand-by-exemplaar. Zie Een licentievrije stand-byreplica configureren voor SQL Managed Instance voor meer informatie.

Zie serviceprijzen voor meer informatie over prijzen van SQL Managed Instance.

Ondersteuning voor meerdere regio's configureren

Zie Een failovergroep configureren voor SQL Managed Instance voor meer informatie over het configureren van een failovergroep.

Capaciteitsplanning en -beheer

Tijdens een failover wordt verkeer omgeleid naar een secundair met SQL beheerd exemplaar. Het is belangrijk dat uw secundaire met SQL beheerde exemplaar gereed is voor het ontvangen van verkeer. Maak een secundair sql-beheerd exemplaar met dezelfde servicelaag, hardwaregeneratie en rekenkracht als het primaire exemplaar.

Zie Exemplaren schalen voor meer informatie over het schalen van met SQL beheerde exemplaren in een failovergroep.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer SQL Managed Instances zijn geconfigureerd voor het gebruik van failovergroepen voor meerdere regio's en alle regio's operationeel zijn:

  • Verkeersroutering tussen regio's: Tijdens normale bewerkingen gaan lees-/schrijfaanvragen naar het ene primaire exemplaar in de primaire regio.

    Failovergroepen bieden ook een afzonderlijk eindpunt voor alleen-lezen listener. Tijdens normale bewerkingen maakt dit eindpunt verbinding met het secundaire exemplaar om alleen-lezenverkeer te routeren dat is opgegeven in de verbindingsreeks.

    Zie Overzicht van failovergroepen en beste praktijken voor meer informatie over hoe failovergroepen het verkeer naar elk exemplaar leiden en hoe u verkeer kunt sturen naar een alleen-lezen-listener-eindpunt.

  • Gegevensreplicatie tussen regio's: Standaard worden gegevens asynchroon van het primaire exemplaar naar het secundaire met SQL beheerde exemplaar gerepliceerd.

    Omdat geo-replicatie asynchroon is, is het mogelijk om gegevensverlies te ervaren als u een geforceerde failover uitvoert. U kunt de replicatievertraging bewaken om inzicht te krijgen in het potentiële gegevensverlies tijdens een geforceerde failover. Zie de controlelijst voor herstel na noodgevallen voor meer informatie.

    Als u gegevensverlies van asynchrone replicatie tijdens failovers wilt elimineren, configureert u uw toepassing om de aanroepende thread te blokkeren totdat wordt bevestigd dat de laatste doorgevoerde transactie is verzonden en beveiligd in het transactielogboek van de secundaire database. Voor deze aanpak is aangepaste ontwikkeling vereist en worden de prestaties van uw toepassing verminderd. Zie Verlies van kritieke gegevens voorkomen voor meer informatie.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer beheerde SQL-exemplaren zijn geconfigureerd voor het gebruik van failovergroepen voor meerdere regio's en er een storing is in de primaire regio:

  • Detectie en reactie: De verantwoordelijkheid voor detectie en reactie is afhankelijk van het failoverbeleid dat door uw failovergroep wordt gebruikt.

    • Door de klant beheerd failoverbeleid: U bent verantwoordelijk voor het detecteren van de fout in een regio en het activeren van een failover of geforceerde failover naar het secundaire exemplaar in de failovergroep.

      Als u een failover uitvoert, wacht SQL Managed Instance tot gegevens worden gesynchroniseerd met het secundaire exemplaar voordat de failoverprocedure wordt uitgevoerd.

      Als u een geforceerde failover uitvoert, schakelt SQL Managed Instance het secundaire exemplaar onmiddellijk over naar de primaire rol zonder te wachten op recente wijzigingen die vanaf de primaire worden doorgegeven. Dit type failover kan gegevensverlies veroorzaken.

    • Door Microsoft beheerd failoverbeleid: Door Microsoft beheerde failovers worden onder uitzonderlijke omstandigheden uitgevoerd. Wanneer Microsoft een failover activeert, voert de failovergroep automatisch een geforceerde failover uit naar het secundaire exemplaar in de failovergroep. Het is echter raadzaam om een door de klant beheerd failoverbeleid te gebruiken voor productieworkloads, zodat u kunt bepalen wanneer de failover plaatsvindt.

  • Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Resource Health echter gebruiken om te controleren op de status van een afzonderlijke resource en u kunt Resource Health-waarschuwingen instellen om u op de hoogte te stellen van problemen. U kunt Azure Service Health ook gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

  • Actieve aanvragen: Wanneer er een failover optreedt, worden alle aanvragen die worden verwerkt, beëindigd en moeten ze opnieuw worden geprobeerd. Zie Tolerantie voor tijdelijke fouten om uw toepassingen tolerant te maken voor dit soort problemen.

  • Verwachte gegevensverlies: De hoeveelheid gegevensverlies is afhankelijk van hoe u uw toepassing configureert. Zie Overzicht van failovergroepen en aanbevolen procedures voor meer informatie.

  • Verwachte downtime: Er kan een kleine hoeveelheid downtime optreden tijdens een failover in de failovergroep. De downtime is doorgaans minder dan 60 seconden.

  • Verkeer omleiden: Nadat de failovergroep het failoverproces heeft voltooid, wordt lees-/schrijfverkeer automatisch doorgestuurd naar het nieuwe primaire exemplaar. Als uw toepassingen de eindpunten van de failovergroep in hun verbindingsreeksen gebruiken, hoeven ze hun verbindingsreeksen niet te wijzigen na een failover.

Herstel van de regio

Failovergroepen starten niet automatisch een failback naar de primaire regio wanneer deze wordt hersteld. Het is dus uw verantwoordelijkheid om een failback te starten.

Test voor regiofouten

U kunt de failover van een failovergroep testen.

Het testen van een failovergroep is slechts één onderdeel van het uitvoeren van een noodherstel-oefening. Zie Dr-oefeningen uitvoeren voor meer informatie.

Backups en herstel

Maak back-ups van uw databases om te beschermen tegen verschillende risico's, waaronder verlies van gegevens. Back-ups kunnen worden hersteld om te herstellen van onbedoeld gegevensverlies, beschadiging of andere problemen. Back-ups zijn niet hetzelfde als geo-replicatie, en ze hebben verschillende doeleinden en beperken verschillende risico's.

Sql Managed Instance maakt automatisch volledige back-ups, differentiële back-ups en transactielogboeken van uw databases. Zie Automatische back-ups in SQL Managed Instance voor meer informatie over de typen back-ups, hun frequentie, herstelmogelijkheden, opslagkosten en back-upversleuteling.

SQL Managed Instance biedt ingebouwde geautomatiseerde back-ups en ondersteunt ook door gebruikers geïnitieerde copy-only back-ups voor gebruikersdatabases. Zie Alleen-kopiëren back-ups voor meer informatie.

Back-upreplicatie

Wanneer u geautomatiseerde back-ups configureert voor uw met SQL beheerde exemplaar, kunt u opgeven hoe back-ups moeten worden gerepliceerd. Back-ups die zijn geconfigureerd om te worden opgeslagen op ZRS hebben een hoger tolerantieniveau. U wordt aangeraden uw back-ups te configureren voor het gebruik van een van de volgende opslagtypen:

  • ZRS voor tolerantie binnen de regio, als de regio beschikbaarheidszones heeft

  • GZRS om de tolerantie van uw back-ups in verschillende regio's te verbeteren als de regio beschikbaarheidszones heeft en is gekoppeld aan een andere regio

  • GRS als uw regio geen ondersteuning biedt voor beschikbaarheidszones, maar wel een gekoppelde regio heeft

Zie Back-up-opslagredundantie voor meer informatie over verschillende soorten opslag en hun mogelijkheden.

Geo-herstel

De mogelijkheid voor geo-herstel is een eenvoudige noodhersteloplossing waarmee u back-upkopieën naar een andere Azure-regio kunt herstellen. Geo-back-up vereist doorgaans een aanzienlijke hoeveelheid downtime en gegevensverlies. Als u een hoger herstelniveau wilt bereiken als er een regionale onderbreking optreedt, moet u failovergroepen configureren.

Als u geo-herstel gebruikt, moet u overwegen hoe u uw back-ups beschikbaar maakt in uw secundaire regio:

  • Als uw primaire regio is gekoppeld, gebruikt u GZRS- of GRS-back-upopslag ter ondersteuning van geo-herstel naar de gekoppelde regio.

  • Als uw primaire regio niet is gekoppeld, kunt u een aangepaste oplossing bouwen om uw back-ups te repliceren naar een andere regio. Overweeg door de gebruiker geïnitieerde back-ups met alleen kopiëren te gebruiken en op te slaan in een opslagaccount dat gebruikmaakt van blobobjectreplicatie om te repliceren naar een opslagaccount in een andere regio.

Tolerantie voor serviceonderhoud

Wanneer SQL Managed Instance onderhoud uitvoert op uw exemplaar, blijft het beheerde SQL-exemplaar volledig beschikbaar, maar kan het worden onderworpen aan korte herconfiguraties. Clienttoepassingen kunnen korte verbindingsonderbrekingen observeren wanneer er een onderhoudsevenement plaatsvindt. Uw clienttoepassingen moeten de richtlijnen voor resistentie tegen tijdelijke fouten volgen om de effecten te minimaliseren.

Met SQL Managed Instance kunt u een onderhoudsvenster opgeven dat doorgaans wordt gebruikt voor service-upgrades en andere onderhoudsbewerkingen. Het configureren van een onderhoudsvenster kan u helpen bij het minimaliseren van eventuele bijwerkingen, zoals automatische failovers, tijdens uw kantooruren. U kunt ook vooraf meldingen ontvangen over gepland onderhoud.

Zie het venster Onderhoud in SQL Managed Instance voor meer informatie.

Diensteniveauovereenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

Voor SQL Managed Instance is de SLA voor beschikbaarheid alleen van toepassing wanneer uw virtuele Azure-netwerk correct is geconfigureerd, zodat het beheerverkeer niet wordt belemmerd. Deze configuratie omvat subnetgrootte, netwerkbeveiligingsgroepen (NSG's), door de gebruiker gedefinieerde routes (UDR's), DNS-configuratie en andere resources die van invloed zijn op het beheer en het gebruik van netwerkresources. Zie Netwerkvereisten voor meer informatie over de vereiste netwerkconfiguratie voor SQL Managed Instance.

Verwante inhoud

  • Last updated on