Groepen voor automatische failover gebruiken om transparante en gecoördineerde geo-failover van meerdere databases mogelijk te maken

VAN TOEPASSING OP: Azure SQL Database Azure SQL Managed Instance

Met groepen voor automatische failover kunt u de replicatie en failover van een groep databases op een server of alle databases in een beheerd exemplaar naar een andere regio beheren. Het is een declaratieve abstractie boven op de bestaande functie voor actieve geo-replicatie, ontworpen om de implementatie en het beheer van geo-gerepliceerde databases op schaal te vereenvoudigen. U kunt een geo-failover handmatig initiëren of u kunt deze delegeren aan de Azure-service op basis van een door de gebruiker gedefinieerd beleid. Met de laatste optie kunt u automatisch meerdere gerelateerde databases in een secundaire regio herstellen na een onherstelbare fout of andere niet-geplande gebeurtenis die resulteert in volledig of gedeeltelijk verlies van de beschikbaarheid van het SQL Database of SQL Managed Instance in de primaire regio. Een failovergroep kan een of meer databases bevatten, die doorgaans door dezelfde toepassing worden gebruikt. Daarnaast kunt u de leesbare secundaire databases gebruiken om alleen-lezen querywerkbelastingen te offloaden.

Wanneer u groepen voor automatische failover met beleid voor automatische failover gebruikt, leidt een storing die van invloed is op een of meer databases in de groep tot een automatische geo-failover. Dit zijn meestal uitval die niet automatisch kan worden opgelost door de ingebouwde infrastructuur voor hoge beschikbaarheid. Voorbeelden van geo-failovertriggers zijn een incident dat wordt veroorzaakt doordat een SQL Database-tenantring of besturingsring niet actief is vanwege een kernelgeheugenlek in het besturingssysteem op rekenknooppunten, of een incident dat wordt veroorzaakt doordat een of meer tenantringen uitvallen omdat een verkeerde netwerkkabel per ongeluk is geknipt tijdens het buiten gebruik stellen van routinehardware. Zie Hoge beschikbaarheid SQL Database voor meer informatie.

Bovendien bieden groepen voor automatische failover eindpunten voor lezen/schrijven en alleen-lezen listeners die ongewijzigd blijven tijdens geo-failovers. Of u nu handmatige of automatische failoveractivering gebruikt, met een geo-failover worden alle secundaire databases in de groep overgeschakeld naar de primaire rol. Nadat de geo-failover is voltooid, wordt de DNS-record automatisch bijgewerkt om de eindpunten om te leiden naar de nieuwe regio. Zie Overzicht van bedrijfscontinuïteit voor RPO en RTO voor geo-failover.

Wanneer u groepen voor automatische failover met beleid voor automatische failover gebruikt, leidt een storing die van invloed is op databases op een server of beheerd exemplaar tot een automatische geo-failover.

U kunt een groep voor automatische failover beheren met behulp van:

• Azure-portal
• Azure CLI: Failovergroep
• PowerShell: failovergroep
• REST API: Failovergroep

Zorg er bij het configureren van een failovergroep voor dat de verificatie en netwerktoegang op de secundaire groep is ingesteld om correct te functioneren na geo-failover, wanneer de geo-secundaire de nieuwe primaire wordt. Zie Beveiliging na SQL Database na noodherstel voor meer informatie.

Voor volledige bedrijfscontinuïteit maakt het toevoegen van regionale database-redundantie slechts deel uit van de oplossing. Het end-to-end herstellen van een toepassing (service) na een onherstelbare fout vereist herstel van alle onderdelen waar de service deel van vormt en alle afhankelijke services. Voorbeelden van deze onderdelen zijn de clientsoftware (bijvoorbeeld een browser met een aangepaste JavaScript), webfront-ends, opslag en DNS. Het is essentieel dat alle onderdelen bestand zijn tegen dezelfde fouten en beschikbaar komen binnen de RTO (Recovery Time Objective) van uw toepassing. Daarom moet u alle afhankelijke services identificeren en inzicht krijgen in de garanties en mogelijkheden die ze bieden. Vervolgens moet u voldoende stappen ondernemen om ervoor te zorgen dat uw service functioneert tijdens de failover van de services waarvan deze afhankelijk is. Zie Cloudoplossingen ontwerpen voor herstel na noodherstel met behulp van actieve geo-replicatie voor meer informatie over het ontwerpen van oplossingen voor herstel na noodherstel.

Terminologie en mogelijkheden voor failovergroep

• Failovergroep (VOOR)

  Een failovergroep is een benoemde groep databases die wordt beheerd door één server of binnen een beheerd exemplaar die als een failover naar een andere regio een failover kan hebben voor het geval alle of sommige primaire databases niet beschikbaar zijn vanwege een storing in de primaire regio. Wanneer deze is gemaakt voor SQL Managed Instance, bevat een failovergroep alle gebruikersdatabases in het exemplaar en kan daarom slechts één failovergroep worden geconfigureerd op een exemplaar.

  Belangrijk

  De naam van de failovergroep moet wereldwijd uniek zijn binnen het .database.windows.net domein.

• Servers

  Sommige of alle gebruikersdatabases op een logische server kunnen in een failovergroep worden geplaatst. Een server ondersteunt ook meerdere failovergroepen op één server.

• Primair

  De server of het beheerde exemplaar dat de primaire databases in de failovergroep host.

• Secundair

  De server of het beheerde exemplaar dat de secundaire databases in de failovergroep host. De secundaire kan zich niet in dezelfde regio als de primaire regio.

• Individuele databases toevoegen aan failovergroep

  U kunt meerdere individuele databases op dezelfde server in dezelfde failovergroep zetten. Als u één database aan de failovergroep toevoegt, wordt automatisch een secundaire database gemaakt met dezelfde editie en rekenkracht op de secundaire server. U hebt die server opgegeven toen de failovergroep werd gemaakt. Als u een database toevoegt die al een secundaire database op de secundaire server heeft, wordt die geo-replicatiekoppeling overgenomen door de groep. Wanneer u een database toevoegt die al een secundaire database heeft op een server die geen deel uitmaakt van de failovergroep, wordt er een nieuwe secundaire database gemaakt op de secundaire server.

  Belangrijk

  Zorg ervoor dat de secundaire server geen database met dezelfde naam heeft, tenzij het een bestaande secundaire database is. In failovergroepen voor SQL Managed Instance worden alle gebruikersdatabases gerepliceerd. U kunt geen subset van gebruikersdatabases kiezen voor replicatie in de failovergroep.

• Databases toevoegen aan een failovergroep in een elastische pool

  U kunt alle of meerdere databases binnen een elastische pool in dezelfde failovergroep zetten. Als de primaire database zich in een elastische pool, wordt de secundaire database automatisch gemaakt in de elastische pool met dezelfde naam (secundaire pool). U moet ervoor zorgen dat de secundaire server een elastische pool bevat met dezelfde exacte naam en voldoende vrije capaciteit om de secundaire databases te hosten die door de failovergroep worden gemaakt. Als u een database toevoegt aan de pool die al een secundaire database in de secundaire pool heeft, wordt die geo-replicatiekoppeling overgenomen door de groep. Wanneer u een database toevoegt die al een secundaire database heeft op een server die geen deel uitmaakt van de failovergroep, wordt er een nieuwe secundaire database gemaakt in de secundaire pool.

• Eerste seeding

  Wanneer u databases, elastische pools of beheerde exemplaren toevoegt aan een failovergroep, is er een eerste seedingfase voordat de gegevensreplicatie wordt gestart. De eerste seedingfase is de langste en duurste bewerking. Zodra de initiële seeding is voltooid, worden gegevens gesynchroniseerd en worden alleen de volgende gegevenswijzigingen gerepliceerd. De tijd die nodig is om de eerste seeding te voltooien, is afhankelijk van de grootte van uw gegevens, het aantal gerepliceerde databases, de belasting van primaire databases en de snelheid van de koppeling tussen de primaire en secundaire database. Onder normale omstandigheden is de mogelijke seeding-snelheid maximaal 500 GB per uur voor SQL Database en maximaal 360 GB per uur voor SQL Managed Instance. Seeding wordt parallel uitgevoerd voor alle databases.

  Voor SQL Managed Instance moet u rekening houden met de snelheid van de Express Route-koppeling tussen de twee exemplaren bij het schatten van de tijd van de eerste seedingfase. Als de snelheid van de koppeling tussen de twee exemplaren langzamer is dan nodig is, zal de tijd tot seed waarschijnlijk aanzienlijk worden beïnvloed. U kunt de opgegeven seedingsnelheid, het aantal databases, de totale grootte van de gegevens en de snelheid van de koppeling gebruiken om te schatten hoelang de eerste seedingfase duurt voordat de gegevensreplicatie begint. Voor een individuele database van 100 GB duurt de eerste seed-fase bijvoorbeeld ongeveer 1,2 uur als de koppeling 84 GB per uur kan pushen en als er geen andere databases worden geseed. Als de koppeling slechts 10 GB per uur kan overdragen, duurt het ongeveer 10 uur om een database van 100 GB te seeden. Als er meerdere databases moeten worden gerepliceerd, wordt seeding parallel uitgevoerd. In combinatie met een trage verbindingssnelheid kan de eerste seedingfase aanzienlijk langer duren, met name als het parallel seeden van gegevens uit alle databases de beschikbare bandbreedte voor de koppeling overschrijdt. Als de netwerkbandbreedte tussen twee exemplaren beperkt is en u meerdere beheerde exemplaren aan een failovergroep toevoegt, kunt u overwegen meerdere beheerde exemplaren opeenvolgend toe te voegen aan de failovergroep, één voor één. Gezien een gateway-SKU van de juiste grootte tussen de twee beheerde exemplaren en als de bandbreedte van het bedrijfsnetwerk dit toestaat, is het mogelijk om snelheden van 360 GB per uur te bereiken.

• DNS-zone

  Een unieke id die automatisch wordt gegenereerd wanneer een nieuw SQL Managed Instance wordt gemaakt. Er wordt een SAN-certificaat (multi-domain) voor dit exemplaar ingericht om de clientverbindingen met elk exemplaar in dezelfde DNS-zone te verifiëren. De twee beheerde exemplaren in dezelfde failovergroep moeten de DNS-zone delen.

  Notitie

  Een DNS-zone-id is niet vereist of wordt gebruikt voor failovergroepen die zijn gemaakt voor SQL Database.

• Lees-/schrijflistener voor failovergroep

  Een DNS CNAME-record die naar de huidige primaire record wijst. Deze wordt automatisch gemaakt wanneer de failovergroep wordt gemaakt en zorgt ervoor dat de lees-/schrijfworkload transparant opnieuw verbinding kan maken met de primaire wanneer de primaire verandert na een failover. Wanneer de failovergroep op een server wordt gemaakt, wordt de DNS CNAME-record voor de listener-URL gevormd als <fog-name>.database.windows.net . Wanneer de failovergroep wordt gemaakt op een SQL Managed Instance, wordt de DNS CNAME-record voor de listener-URL gevormd als <fog-name>.<zone_id>.database.windows.net .

• Alleen-lezen listener voor failovergroep

  Een DNS CNAME-record die naar de huidige secundaire record wijst. Deze wordt automatisch gemaakt wanneer de failovergroep wordt gemaakt en zorgt ervoor dat de alleen-lezen SQL-werkbelasting transparant verbinding kan maken met de secundaire wanneer de secundaire verandert na een failover. Wanneer de failovergroep op een server wordt gemaakt, wordt de DNS CNAME-record voor de listener-URL gevormd als <fog-name>.secondary.database.windows.net . Wanneer de failovergroep wordt gemaakt op een SQL Managed Instance, wordt de DNS CNAME-record voor de listener-URL gevormd als <fog-name>.secondary.<zone_id>.database.windows.net .

• Beleid voor automatische failover

  Standaard wordt een failovergroep geconfigureerd met een beleid voor automatische failover. Het systeem activeert een geo-failover nadat de fout is gedetecteerd en de respijtperiode is verlopen. Het systeem moet controleren of de storing niet kan worden opgelost door de ingebouwdeinfrastructuur voor hoge beschikbaarheid, bijvoorbeeld vanwege de schaal van de impact. Als u de werkstroom voor geo-failover wilt beheren vanuit de toepassing of handmatig, kunt u automatisch failoverbeleid uitschakelen.

  Notitie

  Omdat bij verificatie van de schaal van de storing en hoe snel deze kan worden beperkt menselijke acties nodig zijn, kan de respijtperiode niet minder dan één uur worden ingesteld. Deze beperking geldt voor alle databases in de failovergroep, ongeacht hun gegevenssynchronisatie.

• Failoverbeleid voor alleen-lezen

  De failover van de alleen-lezen listener is standaard uitgeschakeld. Het zorgt ervoor dat de prestaties van de primaire niet worden beïnvloed wanneer de secundaire offline is. Dit betekent echter ook dat de alleen-lezensessies geen verbinding kunnen maken totdat de secundaire is hersteld. Als u downtime voor de alleen-lezensessies niet kunt tolereren en de primaire kunt gebruiken voor zowel alleen-lezen- als lees-/schrijfverkeer ten koste van de potentiële prestatievermindering van de primaire, kunt u failover inschakelen voor de alleen-lezen listener door de eigenschap te AllowReadOnlyFailoverToPrimary configureren. In dat geval wordt het alleen-lezenverkeer automatisch omgeleid naar de primaire als de secundaire niet beschikbaar is.

  Notitie

  De AllowReadOnlyFailoverToPrimary eigenschap heeft alleen effect als automatisch failoverbeleid is ingeschakeld en een automatische geo-failover is geactiveerd. Als in dat geval de eigenschap is ingesteld op Waar, dient de nieuwe primaire functie zowel voor lezen/schrijven als voor alleen-lezensessies.

• Geplande failover

  Geplande failover voert volledige gegevenssynchronisatie uit tussen primaire en secundaire databases voordat de secundaire database overschakelt naar de primaire rol. Dit garandeert geen gegevensverlies. Geplande failover wordt gebruikt in de volgende scenario's:

  • Dr-hersteloefeningen uitvoeren in productie wanneer gegevensverlies niet acceptabel is
  • De databases verplaatsen naar een andere regio
  • De databases terug te brengen naar de primaire regio nadat de storing is vereengeld (failback)

• Niet-geplande failover

  Met niet-geplande of geforceerd failover wordt de secundaire functie onmiddellijk overgezet naar de primaire rol zonder te wachten tot recente wijzigingen van de primaire rol worden doorgegeven. Deze bewerking kan leiden tot gegevensverlies. Niet-geplande failover wordt gebruikt als een herstelmethode tijdens uitval wanneer de primaire niet toegankelijk is. Wanneer de storing is vereenzaakt, maakt de oude primaire automatisch opnieuw verbinding en wordt deze een nieuwe secundaire. Een geplande failover kan worden uitgevoerd om een failback uit te voeren, en de replica's terug te brengen naar de oorspronkelijke primaire en secundaire rollen.

• Handmatige failover

  U kunt een geo-failover op elk moment handmatig initiëren, ongeacht de configuratie van de automatische failover. Als er geen beleid voor automatische failover is geconfigureerd tijdens een storing die van invloed is op het primaire, is een handmatige failover vereist om de secundaire naar de primaire rol te promoveren. U kunt een geforceerd (ongeplande) of gebruiksvriendelijke (geplande) failover initiëren. Een gebruiksvriendelijke failover is alleen mogelijk wanneer de oude primaire regio toegankelijk is en kan worden gebruikt om de primaire regio zonder gegevensverlies naar de secundaire regio te verplaatsen. Wanneer een failover is voltooid, worden de DNS-records automatisch bijgewerkt om verbinding te maken met de nieuwe primaire server.

• Respijtperiode met gegevensverlies

  Omdat de secundaire databases worden gesynchroniseerd met behulp van asynchrone replicatie, kan een automatische geo-failover leiden tot gegevensverlies. U kunt het beleid voor automatische failover aanpassen aan de tolerantie van uw toepassing voor gegevensverlies. Door te configureren, kunt u bepalen hoe lang het systeem wacht voordat een geforceerd failover wordt geïnitieerd, wat kan leiden GracePeriodWithDataLossHours tot gegevensverlies.

• Meerdere failovergroepen

  U kunt meerdere failovergroepen configureren voor hetzelfde paar servers om het bereik van geo-failovers te beheren. Elke groep wordt onafhankelijk van elkaar overgenomen. Als uw tenant-per-database-toepassing is geïmplementeerd in meerdere regio's en elastische pools gebruikt, kunt u deze mogelijkheid gebruiken om primaire en secundaire databases in elke pool te combineren. Op deze manier kunt u de impact van een storing mogelijk beperken tot slechts enkele tenantdatabases.

  Notitie

  SQL Managed Instance biedt geen ondersteuning voor meerdere failovergroepen.

Machtigingen

Machtigingen voor een failovergroep worden beheerd via op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC). De SQL Server inzender heeft alle benodigde machtigingen voor het beheren van failovergroepen.

Een failovergroep maken

Als u een failovergroep wilt maken, hebt u schrijftoegang van Azure RBAC nodig tot zowel de primaire als de secundaire servers en alle databases in de failovergroep. Voor een SQL Managed Instance hebt u Schrijftoegang van Azure RBAC nodig tot zowel het primaire als het secundaire SQL Managed Instance, maar machtigingen voor afzonderlijke databases zijn niet relevant, omdat afzonderlijke SQL Managed Instance-databases niet kunnen worden toegevoegd aan of verwijderd uit een failovergroep.

Een failovergroep bijwerken

Als u een failovergroep wilt bijwerken, hebt u schrijftoegang van Azure RBAC nodig tot de failovergroep en alle databases op de huidige primaire server of het huidige beheerde exemplaar.

Failover van een failovergroep

Als u een failovergroep wilt uitvoeren, hebt u schrijftoegang van Azure RBAC nodig tot de failovergroep op de nieuwe primaire server of het beheerde exemplaar.

Best practices voor failovergroep voor SQL Database

De groep voor automatische failover moet worden geconfigureerd op de primaire server en deze verbinden met de secundaire server in een andere Azure-regio. De groepen kunnen alle of sommige databases in deze servers bevatten. Het volgende diagram illustreert een typische configuratie van een geografisch redundante cloudtoepassing met behulp van meerdere databases en een groep voor automatische failover.

Volg deze algemene richtlijnen bij het ontwerpen van een service met bedrijfscontinuïteit in het achterhoofd:

Een of meer failovergroepen gebruiken om failovers van meerdere databases te beheren

Er kunnen een of meer failovergroepen worden gemaakt tussen twee servers in verschillende regio's (primaire en secundaire servers). Elke groep kan een of meer databases bevatten die als eenheid worden hersteld voor het geval alle of sommige primaire databases niet meer beschikbaar zijn vanwege een storing in de primaire regio. Als u een failovergroep maakt, worden geo-secundaire databases gemaakt met dezelfde servicedoelstelling als de primaire database. Als u een bestaande geo-replicatierelatie toevoegt aan een failovergroep, moet u ervoor zorgen dat de geo-secundaire laag is geconfigureerd met dezelfde servicelaag en rekenkracht als de primaire.

De lees-/schrijflistener gebruiken om verbinding te maken met de primaire

Gebruik voor lees-/schrijfworkloads <fog-name>.database.windows.net als de servernaam in de connection string. Verbindingen worden automatisch omgeleid naar de primaire. Deze naam verandert niet na een failover. De failover omvat het bijwerken van de DNS-record, zodat de clientverbindingen pas worden omgeleid naar de nieuwe primaire server nadat de DNS-cache van de client is vernieuwd. De TTL (Time to Live) van de DNS-record van de primaire en secundaire listener is 30 seconden.

De alleen-lezen listener gebruiken om verbinding te maken met geo-secundaire

Als u logisch geïsoleerde alleen-lezenworkloads hebt die tolerant zijn voor gegevenslatentie, kunt u ze uitvoeren op de geo-secundaire locatie. Gebruik voor alleen-lezensessies <fog-name>.secondary.database.windows.net als servernaam in de connection string. Verbindingen worden automatisch omgeleid naar de geo-secundaire locatie. Het wordt ook aanbevolen dat u de leesintentie in de connection string met behulp van ApplicationIntent=ReadOnly .

Mogelijke prestatievermindering na geo-failover

Een typische Azure-toepassing maakt gebruik van meerdere Azure-services en bestaat uit meerdere onderdelen. De automatische geo-failover van de failovergroep wordt geactiveerd op basis van de status SQL Azure-onderdelen. Andere Azure-services in de primaire regio worden mogelijk niet beïnvloed door de storing en de onderdelen ervan zijn mogelijk nog steeds beschikbaar in die regio. Zodra de primaire databases overschakelen naar de secundaire regio (DR), kan de latentie tussen de afhankelijke onderdelen toenemen. Om de gevolgen van een hogere latentie op de prestaties van de toepassing te voorkomen, moet u de redundantie van alle onderdelen van de toepassing in de DR-regio garanderen, deze richtlijnen voor netwerkbeveiliging volgen en de geo-failover van relevante toepassingsonderdelen samen met de database indelen.

Mogelijk gegevensverlies na geo-failover

Als er een storing optreedt in de primaire regio, kunnen recente transacties mogelijk niet worden gerepliceerd naar de geo-secundaire regio. Als het beleid voor automatische failover is geconfigureerd, wacht het systeem op de periode die u hebt opgegeven door voordat een automatische GracePeriodWithDataLossHours geo-failover wordt geïnitieerd. De standaardwaarde is 1 uur. Dit geeft de voorkeur aan beschikbaarheid van databases boven gegevensverlies. Door in te stellen op een groter aantal, zoals 24 uur of het uitschakelen van automatische geo-failover, kunt u de kans op gegevensverlies verminderen ten koste van de GracePeriodWithDataLossHours beschikbaarheid van de database.

De secundaire regio van een failovergroep wijzigen

Ter illustratie van de wijzigingsreeks gaan we ervan uit dat server A de primaire server is, server B de bestaande secundaire server is en server C de nieuwe secundaire server in de derde regio. Volg deze stappen om de overgang te maken:

1. Maak aanvullende secondaries van elke database op server A naar server C met behulp van actieve geo-replicatie. Elke database op server A heeft twee secondaries, één op server B en één op server C. Dit garandeert dat de primaire databases tijdens de overgang beveiligd blijven.
2. Verwijder de failovergroep. Aanmeldingspogingen met failovergroep-eindpunten mislukken op dit moment.
3. Maak de failovergroep opnieuw met dezelfde naam tussen servers A en C.
4. Voeg alle primaire databases op server A toe aan de nieuwe failovergroep. Op dit moment mislukken de aanmeldingspogingen niet meer.
5. Verwijder server B. Alle databases op B worden automatisch verwijderd.

De primaire regio van een failovergroep wijzigen

Ter illustratie van de wijzigingsreeks gaan we ervan uit dat server A de primaire server is, server B de bestaande secundaire server is en server C de nieuwe primaire server in de derde regio. Volg deze stappen om de overgang te maken:

1. Voer een geplande geo-failover uit om de primaire server over te schakelen naar B. Server A wordt de nieuwe secundaire server. De failover kan enkele minuten downtime tot gevolg hebben. De werkelijke tijd is afhankelijk van de grootte van de failovergroep.
2. Maak extra secondaries van elke database op server B naar server C met behulp van actieve geo-replicatie. Elke database op server B heeft twee secondaries, één op server A en één op server C. Dit garandeert dat de primaire databases tijdens de overgang beveiligd blijven.
3. Verwijder de failovergroep. Aanmeldingspogingen met failovergroep-eindpunten mislukken op dit moment.
4. Maak de failovergroep opnieuw met dezelfde naam tussen servers B en C.
5. Voeg alle primaire databases op B toe aan de nieuwe failovergroep. Op dit moment mislukken de aanmeldingspogingen niet meer.
6. Voer een geplande geo-failover van de failovergroep uit om van B en C te wisselen. Server C wordt nu de primaire server en B de secundaire server. Alle secundaire databases op server A worden automatisch gekoppeld aan de primaireries op C. Net als in stap 1 kan de failover enkele minuten downtime tot gevolg hebben.
7. Verwijder server A. Alle databases op A worden automatisch verwijderd.

Best practices voor failovergroep voor SQL Managed Instance

De groep voor automatische failover moet worden geconfigureerd op het primaire exemplaar en wordt verbonden met het secundaire exemplaar in een andere Azure-regio. Alle gebruikersdatabases in het exemplaar worden gerepliceerd naar het secundaire exemplaar. Systeemdatabases zoals master en msdb worden niet gerepliceerd.

In het volgende diagram ziet u een typische configuratie van een geografisch redundante cloudtoepassing met behulp van een beheerd exemplaar en een groep voor automatische failover.

Als uw toepassing gebruikmaakt SQL Managed Instance als de gegevenslaag, volgt u deze algemene richtlijnen bij het ontwerpen voor bedrijfscontinuïteit:

Het beheerde geo-secundaire exemplaar maken

Om ervoor te zorgen dat de verbinding met het primaire SQL managed instance na een failover wordt onderbroken, moeten zowel de primaire als de secundaire instantie zich in dezelfde DNS-zone bevindt. Dit garandeert dat hetzelfde SAN-certificaat (multi-domain) kan worden gebruikt voor het verifiëren van clientverbindingen met een van de twee exemplaren in de failovergroep. Wanneer uw toepassing gereed is voor productie-implementatie, maakt u een secundair SQL Managed Instance in een andere regio en zorgt u ervoor dat deze de DNS-zone deelt met de primaire SQL Managed Instance. U kunt dit doen door tijdens het maken een optionele parameter op te geven. Als u PowerShell of de REST API gebruikt, is de naam van de optionele parameter DNSZonePartner . De naam van het bijbehorende optionele veld in Azure Portal is Primair beheerd exemplaar.

Zie Create a secondary managed instance (Een secundair beheerd exemplaar maken) voor meer informatie over het maken van de secundaire SQL Managed Instance in dezelfde DNS-zone als het primaire exemplaar.

Gekoppelde regio's gebruiken

Implementeer beide beheerde exemplaren in gekoppelde regio's, om prestatieredenen. SQL Failovergroepen van beheerde exemplaren in gekoppelde regio's leveren betere prestaties dan niet-betaalde regio's.

Geo-replicatieverkeer tussen twee beheerde exemplaren inschakelen

Omdat elk beheerd exemplaar is geïsoleerd in een eigen VNet, moet tweerichtingsverkeer tussen deze VNets worden toegestaan. Zie Azure VPN-gateway

Een failovergroep maken tussen beheerde exemplaren in verschillende abonnementen

U kunt een failovergroep maken tussen SQL beheerde exemplaren in twee verschillende abonnementen,zolang abonnementen zijn gekoppeld aan dezelfde Azure Active Directory tenant . Wanneer u de PowerShell-API gebruikt, kunt u dit doen door de parameter op te geven voor de PartnerSubscriptionId secundaire SQL Managed Instance. Wanneer u REST API, kan elke exemplaar-id die is opgenomen in de properties.managedInstancePairs parameter een eigen abonnements-id hebben.

Geo-failover naar een geo-secundair exemplaar beheren

De failovergroep beheert de geo-failover van alle databases op het primaire beheerde exemplaar. Wanneer een groep wordt gemaakt, wordt elke database in het exemplaar automatisch geo-gerepliceerd naar het geo-secundaire exemplaar. U kunt geen failovergroepen gebruiken om een gedeeltelijke failover van een subset van databases te initiëren.

De lees-/schrijf-listener gebruiken om verbinding te maken met het primaire beheerde exemplaar

Voor lees-/schrijfworkloads gebruikt <fog-name>.zone_id.database.windows.net u als servernaam. Verbindingen worden automatisch omgeleid naar de primaire. Deze naam verandert niet na een failover. De geo-failover omvat het bijwerken van de DNS-record, zodat de clientverbindingen pas worden omgeleid naar de nieuwe primaire server nadat de DNS-cache van de client is vernieuwd. Omdat het secundaire exemplaar de DNS-zone deelt met de primaire, kan de clienttoepassing er opnieuw verbinding mee maken met behulp van hetzelfde SAN-certificaat aan de serverzijde.

De alleen-lezen listener gebruiken om verbinding te maken met het geo-secundaire beheerde exemplaar

Als u logisch geïsoleerde alleen-lezen workloads hebt die tolerant zijn voor gegevenslatentie, kunt u ze uitvoeren op de geo-secundaire. Gebruik als servernaam om rechtstreeks verbinding te maken met de <fog-name>.secondary.<zone_id>.database.windows.net geo-secundaire server.

Mogelijke prestatievermindering na failover naar het geo-secundaire beheerde exemplaar

Een typische Azure-toepassing maakt gebruik van meerdere Azure-services en bestaat uit meerdere onderdelen. De automatische geo-failover van de failovergroep wordt geactiveerd op basis van de status SQL Azure-onderdelen. Andere Azure-services in de primaire regio worden mogelijk niet beïnvloed door de storing en de onderdelen ervan zijn mogelijk nog steeds beschikbaar in die regio. Zodra de primaire databases overschakelen naar de secundaire regio, kan de latentie tussen de afhankelijke onderdelen toenemen. Om de gevolgen van een hogere latentie op de prestaties van de toepassing te voorkomen, moet u de redundantie van alle onderdelen van de toepassing in de secundaire regio garanderen en fail over toepassingsonderdelen samen met de database. Volg tijdens de configuratie de richtlijnen voor netwerkbeveiliging om de verbinding met de database in de secundaire regio te garanderen.

Mogelijk gegevensverlies na een failover naar het geo-secundaire beheerde exemplaar

Als er een storing optreedt in de primaire regio, kunnen recente transacties mogelijk niet worden gerepliceerd naar de geo-secundaire regio. Als het beleid voor automatische failover is geconfigureerd, wordt voor onze kennis een geo-failover geactiveerd als er geen gegevens verloren gaan. Anders wordt failover uitgesteld voor de periode die u opgeeft met GracePeriodWithDataLossHours . Als u het beleid voor automatische failover hebt geconfigureerd, moet u voorbereid zijn op gegevensverlies. Over het algemeen geeft Azure tijdens uitval de voorkeur aan beschikbaarheid. Door in te stellen op een groter aantal, zoals 24 uur of het uitschakelen van automatische geo-failover, kunt u de kans op gegevensverlies verminderen ten koste van de GracePeriodWithDataLossHours beschikbaarheid van de database.

De DNS-update van de lees-/schrijf-listener vindt onmiddellijk plaats nadat de failover is gestart. Deze bewerking leidt niet tot gegevensverlies. Het proces van het overschakelen van databaserollen kan onder normale omstandigheden echter wel vijf minuten duren. Totdat dit is voltooid, zijn sommige databases in het nieuwe primaire exemplaar nog steeds alleen-lezen. Als een failover wordt gestart met behulp van PowerShell, is de bewerking om over te schakelen naar de primaire replicarol synchroon. Als deze wordt gestart met behulp van de Azure Portal, geeft de gebruikersinterface de voltooiingsstatus aan. Als het wordt gestart met behulp van REST API, gebruikt u het polling-Azure Resource Manager van Standard Azure Resource Manager om te controleren op voltooiing.

De secundaire regio van de failovergroep van het beheerde exemplaar wijzigen

Stel dat exemplaar A het primaire exemplaar is, instantie B het bestaande secundaire exemplaar is en exemplaar C het nieuwe secundaire exemplaar in de derde regio. Volg deze stappen om de overgang te maken:

1. Maak exemplaar C met dezelfde grootte als A en in dezelfde DNS-zone.
2. Verwijder de failovergroep tussen exemplaar A en B. Op dit moment mislukken de aanmeldingen omdat de SQL-aliassen voor de failovergroeplisteners zijn verwijderd en de gateway de naam van de failovergroep niet herkent. De secundaire databases worden losgekoppeld van de primaireries en worden lees-/schrijfdatabases.
3. Maak een failovergroep met dezelfde naam tussen exemplaar A en C. Volg de instructies in de failovergroep met SQL Managed Instance. Dit is een bewerking voor de grootte van de gegevens en wordt voltooid wanneer alle databases van exemplaar A worden geseed en gesynchroniseerd.
4. Verwijder instantie B als dat niet nodig is om onnodige kosten te voorkomen.

De primaire regio van de failovergroep van het beheerde exemplaar wijzigen

Stel dat exemplaar A het primaire exemplaar is, exemplaar B het bestaande secundaire exemplaar is en exemplaar C het nieuwe primaire exemplaar in de derde regio. Volg deze stappen om de overgang te maken:

1. Maak exemplaar C met dezelfde grootte als B en in dezelfde DNS-zone.
2. Verbinding maken naar instantie B en handmatige failover om het primaire exemplaar over te schakelen naar B. Instantie A wordt automatisch het nieuwe secundaire exemplaar.
3. Verwijder de failovergroep tussen exemplaren A en B. Aanmeldingspogingen met failovergroep-eindpunten mislukken op dit moment. De secundaire databases op A worden losgekoppeld van de primaireries en worden lees-/schrijfdatabases.
4. Maak een failovergroep met dezelfde naam tussen exemplaar A en C. Volg de instructies in de zelfstudie failovergroep met beheerd exemplaar. Dit is een bewerking voor de grootte van de gegevens en wordt voltooid wanneer alle databases van exemplaar A worden geseed en gesynchroniseerd. Op dit moment mislukken aanmeldingspogingen niet meer.
5. Verwijder instantie A als dat niet nodig is om onnodige kosten te voorkomen.

Scenario's inschakelen die afhankelijk zijn van objecten van de systeemdatabases

Systeemdatabases worden niet gerepliceerd naar het secundaire exemplaar in een failovergroep. Als u scenario's wilt inschakelen die afhankelijk zijn van objecten van de systeemdatabases, moet u dezelfde objecten maken op het secundaire exemplaar en ze gesynchroniseerd houden met het primaire exemplaar.

Als u bijvoorbeeld van plan bent om dezelfde aanmeldingen te gebruiken op het secundaire exemplaar, moet u deze maken met de identieke SID.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Exemplaareigenschappen en bewaarbeleid synchroniseren tussen het primaire en secundaire exemplaar

Exemplaren in een failovergroep blijven afzonderlijke Azure-resources en er worden geen wijzigingen aangebracht in de configuratie van het primaire exemplaar automatisch gerepliceerd naar het secundaire exemplaar. Zorg ervoor dat u alle relevante wijzigingen op zowel het primaire als het secundaire exemplaar moet uitvoeren. Als u bijvoorbeeld de redundantie van back-upopslag of het beleid voor langetermijnretentie van back-ups op het primaire exemplaar wijzigt, moet u dit ook op het secundaire exemplaar wijzigen.

Failovergroepen en netwerkbeveiliging

Voor sommige toepassingen vereisen de beveiligingsregels dat de netwerktoegang tot de gegevenslaag is beperkt tot een specifiek onderdeel of bepaalde onderdelen, zoals een VM, webservice, enzovoort. Deze vereiste brengt enkele uitdagingen met zich mee voor het ontwerpen van bedrijfscontinuïteit en het gebruik van failovergroepen. Houd rekening met de volgende opties bij het implementeren van dergelijke beperkte toegang.

Failovergroepen en service-eindpunten voor virtuele netwerken gebruiken

Als u Virtual Network-service-eindpunten en -regels gebruikt om de toegang tot uw database in SQL Database of SQL Managed Instance te beperken, moet u er rekening mee houden dat elk service-eindpunt voor virtuele netwerken slechts op één Azure-regio van toepassing is. Met het eindpunt kunnen andere regio's geen communicatie van het subnet accepteren. Daarom kunnen alleen de clienttoepassingen die in dezelfde regio zijn geïmplementeerd, verbinding maken met de primaire database. Omdat een geo-failover tot gevolg heeft dat de SQL Database-clientsessies worden omgeleid naar een server in een andere (secundaire) regio, mislukken deze sessies als ze afkomstig zijn van een client buiten die regio. Daarom kan het beleid voor automatische failover niet worden ingeschakeld als de deelnemende servers of exemplaren zijn opgenomen in de Virtual Network regels. Volg deze stappen om handmatige failover te ondersteunen:

1. De redundante kopieën van de front-endonderdelen van uw toepassing (webservice, virtuele machines, enzovoort) inrichten in de secundaire regio.
2. Configureer de regels voor virtuele netwerken afzonderlijk voor de primaire en secundaire server.
3. Schakel de front-end-failover in met behulp van een Traffic Manager-configuratie.
4. Start handmatige geo-failover wanneer de storing wordt gedetecteerd. Deze optie is geoptimaliseerd voor de toepassingen waarvoor consistente latentie tussen de front-end en de gegevenslaag is vereist en biedt ondersteuning voor herstel wanneer front-end, gegevenslaag of beide worden beïnvloed door de storing.

Failovergroepen en firewallregels gebruiken

Als voor uw bedrijfscontinuïteitsplan failover is vereist met behulp van groepen met automatische failover, kunt u de toegang tot uw database in SQL Database met behulp van openbare IP-firewallregels. Volg deze stappen om automatische failover te ondersteunen:

1. Een openbaar IP-adres maken
2. Maak een openbaar load balancer en wijs het openbare IP-adres toe.
3. Maak een virtueel netwerk en de virtuele machines voor uw front-endonderdelen.
4. Maak een netwerkbeveiligingsgroep en configureer binnenkomende verbindingen.
5. Zorg ervoor dat de uitgaande verbindingen zijn geopend voor Azure SQL Database in een regio met behulp van een Sql.<Region> servicetag.
6. Maak een SQL Database firewallregel om inkomende verkeer toe te staan vanaf het openbare IP-adres dat u in stap 1 hebt gemaakt.

Zie Uitgaande verbindingen voor load balancer voor meer informatie over het configureren van uitgaande toegang en welk IP-adres moet worden gebruikt in de firewallregels.

De bovenstaande configuratie zorgt ervoor dat een automatische geo-failover verbindingen van de front-endonderdelen niet blokkeert en gaat ervan uit dat de toepassing de langere latentie tussen de front-end en de gegevenslaag kan tolereren.

Geo-replicatie inschakelen tussen virtuele netwerken van beheerde exemplaren

Wanneer u een failovergroep tussen primaire en secundaire SQL managed instances in twee verschillende regio's in te stellen, wordt elk exemplaar geïsoleerd met behulp van een onafhankelijk virtueel netwerk. Zorg ervoor dat aan deze vereisten wordt voldaan om replicatieverkeer tussen deze VNets toe te staan:

• De twee exemplaren van SQL Managed Instance moeten zich in verschillende Azure-regio's.

• De twee exemplaren van SQL Managed Instance moeten dezelfde servicelaag zijn en dezelfde opslaggrootte hebben.

• Uw secundaire exemplaar van SQL Managed Instance moet leeg zijn (geen gebruikersdatabases).

• De virtuele netwerken die worden gebruikt door de exemplaren van SQL Managed Instance moeten worden verbonden via een VPN Gateway of Express Route. Wanneer twee virtuele netwerken verbinding maken via een on-premises netwerk, zorg er dan voor dat er geen firewallregel is die poorten 5022 en 11000-11999 blokkeert. Globale VNet-peering wordt ondersteund maar met de beperking die wordt beschreven in de onderstaande notitie.

  Belangrijk

  Op 22-9-2020is ondersteuning voor wereldwijde peering van virtuele netwerken voor nieuw gemaakte virtuele clusters aangekondigd. Dit betekent dat wereldwijde peering voor virtuele netwerken wordt ondersteund voor SQL beheerde exemplaren die in lege subnetten zijn gemaakt na de aankondigingsdatum, evenals voor alle volgende beheerde exemplaren die in deze subnetten zijn gemaakt. Voor alle andere SQL ondersteuning voor peering van beheerde exemplaren is beperkt tot de netwerken in dezelfde regio vanwege de beperkingen van wereldwijde peering voor virtuele netwerken. Zie ook de relevante sectie van het artikel Veelgestelde vragen over Azure Virtual Networks voor meer informatie. Als u wereldwijde peering voor virtuele netwerken wilt gebruiken voor SQL beheerde exemplaren van virtuele clusters die zijn gemaakt vóór de aankondigingsdatum, kunt u overwegen om een niet-standaard onderhoudsvenster voor de exemplaren te configureren, omdat de exemplaren worden verplaatst naar nieuwe virtuele clusters die ondersteuning bieden voor wereldwijde peering van virtuele netwerken.

• De twee SQL Managed Instance VNets mogen geen overlappende IP-adressen hebben.

• U moet uw netwerkbeveiligingsgroepen (NSG) zodanig instellen dat poort 5022 en het bereik 11000–12000 zijn geopend voor inkomende en uitgaande verbindingen van het subnet van het andere beheerde exemplaar. Dit is om replicatieverkeer tussen de exemplaren mogelijk te maken.

  Belangrijk

  Onjuist geconfigureerde NSG-beveiligingsregels leiden tot vastgelopen database seeding-bewerkingen.

• De secundaire SQL Managed Instance is geconfigureerd met de juiste DNS-zone-id. DNS-zone is een eigenschap van een SQL Managed Instance en het onderliggende virtuele cluster, en de id ervan is opgenomen in het hostnaamadres. De zone-id wordt gegenereerd als een willekeurige tekenreeks wanneer het eerste SQL Managed Instance wordt gemaakt in elk VNet en dezelfde id wordt toegewezen aan alle andere exemplaren in hetzelfde subnet. Zodra de DNS-zone is toegewezen, kan deze niet meer worden gewijzigd. SQL Beheerde exemplaren die zijn opgenomen in dezelfde failovergroep, moeten de DNS-zone delen. U doet dit door de zone-id van het primaire exemplaar door te geven als de waarde van de parameter DnsZonePartner bij het maken van het secundaire exemplaar.

  Notitie

  Zie Een beheerd exemplaar toevoegen aan een failovergroep voor een gedetailleerde zelfstudie over het configureren van failovergroepenmet SQL Managed SQL Instance.

Primaire database schalen

U kunt de primaire database omhoog of omlaag schalen naar een andere rekenkracht (binnen dezelfde servicelaag) zonder de verbinding met geo-secundaire databases te verbreken. Wanneer u omhoog schaalt, raden we u aan eerst de geo-secundaire te schalen en vervolgens de primaire op te schalen. Wanneer u omlaag schaalt, draait u de volgorde om: schaal eerst de primaire en vervolgens omlaag naar de secundaire. Wanneer u een database schaalt naar een andere servicelaag, wordt deze aanbeveling afgedwongen.

Deze reeks wordt specifiek aanbevolen om het probleem te voorkomen waarbij de geo-secundaire SKU bij een lagere SKU overbelast raakt en opnieuw moet worden geseed tijdens een upgrade- of downgradeproces. U kunt dit probleem ook vermijden door het primaire exemplaar alleen-lezen te maken. Dit gaat ten koste van alle lezen/schrijven-werkbelastingen die zijn gekoppeld aan het primaire exemplaar.

Verlies van kritieke gegevens voorkomen

Vanwege de hoge latentie van Wide Area Networks maakt geo-replicatie gebruik van een asynchrone replicatiemechanisme. Asynchrone replicatie maakt de mogelijkheid van gegevensverlies onvermijdelijk als de primaire fout mislukt. Om kritieke transacties te beschermen tegen gegevensverlies, kan een toepassingsontwikkelaar de sp_wait_for_database_copy_sync opgeslagen procedure onmiddellijk na het uitvoeren van de transactie aanroepen. Het aanroepen van blokkeert de aanroepingsthread totdat de laatste vastgelegde transactie is verzonden en gehard sp_wait_for_database_copy_sync in het transactielogboek van de secundaire database. Er wordt echter niet gewacht tot de verzonden transacties opnieuw worden afgespeeld (opnieuw) op de secundaire. sp_wait_for_database_copy_sync is gericht op een specifieke geo-replicatiekoppeling. Elke gebruiker met de verbindingsrechten voor de primaire database kan deze procedure aanroepen.

Failovergroepen en herstel naar een bepaald tijdstip

Zie Herstel naar een bepaald tijdstip (PITR)voor meer informatie over het gebruik van herstel naar een bepaald tijdstip met failovergroepen.

Beperkingen van failovergroepen

Let op de volgende beperkingen:

• Failovergroepen kunnen niet worden gemaakt tussen twee servers of exemplaren in dezelfde Azure-regio.
• De naam van failovergroepen kan niet worden gewijzigd. U moet de groep verwijderen en opnieuw maken met een andere naam.
• De naam van de database wordt niet ondersteund voor databases in een failovergroep. U moet de failovergroep tijdelijk verwijderen om de naam van een database te kunnen wijzigen of om de database uit de failovergroep te verwijderen.
• Systeemdatabases worden niet gerepliceerd naar het secundaire exemplaar in een failovergroep. Voor scenario's die afhankelijk zijn van objecten uit de systeemdatabases, moeten objecten daarom handmatig worden gemaakt op de secundaire exemplaren en moeten ze ook handmatig gesynchroniseerd worden gehouden nadat er wijzigingen zijn aangebracht op het primaire exemplaar. De enige uitzondering hierop is Service Master Key (SMK) voor SQL Managed Instance, dat automatisch wordt gerepliceerd naar het secundaire exemplaar tijdens het maken van de failovergroep. Alle volgende wijzigingen van SMK op het primaire exemplaar worden echter niet gerepliceerd naar het secundaire exemplaar.
• Failovergroepen kunnen niet worden gemaakt tussen exemplaren als een van deze zich in een exemplaargroep.

Failovergroepen programmatisch beheren

Zoals eerder besproken, kunnen groepen voor automatische failover ook programmatisch worden beheerd met Azure PowerShell, Azure CLI en REST API. In de volgende tabellen wordt de set beschikbare opdrachten beschreven. Actieve geo-replicatie bevat een set Azure Resource Manager API's voor beheer, waaronder de cmdlets Azure SQL Database REST API en Azure PowerShell. Deze API's vereisen het gebruik van resourcegroepen en ondersteunen op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC). Zie Op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC)voor meer informatie over het implementeren van toegangsrollen.

Geo SQL Database-failover beheren

Geo-failover SQL managed instance beheren

Volgende stappen

• Zie voor gedetailleerde zelfstudies
  • Een SQL Database aan een failovergroep toevoegen
  • Een elastische pool aan een failovergroep toevoegen
  • Een beheerd SQL toevoegen aan een failovergroep
• Zie voor voorbeeldscripts:
  • PowerShell gebruiken voor het configureren van actieve geo-replicatie voor Azure SQL Database
  • PowerShell gebruiken voor het configureren van actieve geo-replicatie voor een pooldatabase in Azure SQL Database
  • PowerShell gebruiken om een Azure SQL Database aan een failovergroep toe te voegen
• Zie Overzicht van bedrijfscontinuïteit voor een overzicht van bedrijfscontinuïteit en scenario's
• Zie automatische Azure SQL Database voor meer informatie over SQL Database back-ups.
• Zie Een database herstellen vanuit de door de service geïnitieerde back-upsvoor meer informatie over het gebruik van automatische back-ups voor herstel.
• Zie Beveiliging na herstel na noodherstel voor meer informatie over de verificatievereisten voor een SQL Database nieuwe primaireserver en database.