Bedrijfscontinuïteit en herstel na noodgevallen voor sql Managed Instance met Azure Arc

Sql Managed Instance met Azure Arc biedt mogelijkheden voor bedrijfscontinuïteit en herstel na noodgevallen (BCDR) waarmee bedrijven kunnen herstellen van onderbrekingen en met minimale downtime kunnen blijven werken.

Dit artikel bevat belangrijke ontwerpoverwegingen en aanbevelingen voor het configureren en beheren van bedrijfscontinuïteitsmogelijkheden, zoals herstel naar een bepaald tijdstip, hoge beschikbaarheid en herstel na noodgevallen.

Architectuur

In de volgende architectuurdiagrammen ziet u de mogelijkheden voor hoge beschikbaarheid van sql Managed Instance met Arc in de servicelaag Bedrijfskritiek, die failover ondersteunt met bijna nul downtime. Als het primaire exemplaar mislukt, stopt de load balancer met het verzenden van verkeer naar dat exemplaar. Vervolgens promoveert een van de secundaire exemplaren tot de primaire instantie en begint het zojuist gepromoveerde exemplaar lees-schrijfverkeer te ontvangen van de load balancer. Nadat het mislukte exemplaar weer online is, wordt het toegevoegd als een secundair exemplaar.

In het volgende architectuurdiagram ziet u hoe sql Managed Instance met Arc kan worden geïmplementeerd op twee afzonderlijke Kubernetes-clusters in twee verschillende sites voor herstel na noodgevallen.

In het volgende architectuurdiagram ziet u hoe sql Managed Instance met Arc reageert wanneer een failover voor herstel na noodgevallen wordt gestart.

Ontwerpoverwegingen

Bekijk de BCDR-aanbevelingen voor landingszones in Bedrijfscontinuïteit enHerstel na noodgevallen om het effect van Azure Arc-enabled SQL Managed Instance op uw algemene BCDR-model te beoordelen. De focus van Bedrijfscontinuïteit en herstel na noodgevallen is alleen gericht op ontwerpaanbevelingen voor bedrijfscontinuïteit, maar de hoge beschikbaarheid en tolerantie van uw exemplaar is ook afhankelijk van de beschikbaarheid van de onderliggende Kubernetes-infrastructuur.

Herstel naar een bepaald tijdstip

• Definieer uw doelen voor RPO (Recovery Point Objective) en RTO-(Recovery Time Objective).

• Bepaal hoe lang u uw back-ups wilt bewaren en herstellen binnen de ondersteunde bewaarlimieten.

• Houd rekening met de gevolgen voor opslag en de kosten voor het verhogen van de bewaarperiode van uw back-ups. De standaardretentie is zeven dagen. Met deze duur kunt u maximaal zeven dagen herstellen en u krijgt één volledige back-up, een dagelijks differentieel en back-ups van transactionele logboeken ongeveer om de vijf minuten.

• Overweeg welke opslagklasse te gebruiken voor het permanente volume voor back-ups. Voor hulp, zie Storage-disciplines voor Azure Arc-enabled SQL Managed Instance.

• Houd rekening met de grootte van het permanente volume voor back-ups in de context van de verwachte gegevensgrootte en de geconfigureerde bewaarperiode.

• Zie de Storage-disciplines voor sql Managed Instance met Azure Arcvoor aanbevolen procedures voor opslag.

• Back-ups worden altijd uitgevoerd op de primaire replica. Houd rekening met de prestatie-effecten van de back-up- en herstelprocessen bij het identificeren van de resources die aan uw exemplaar zijn toegewezen.

• Houd er rekening mee dat herstel op een specifiek tijdstip van een database een bestaande database niet kan overschrijven. Ze kunnen echter gegevens herstellen naar een nieuwe database op hetzelfde exemplaar.

• Houd rekening met de aanvullende stappen die nodig zijn om uw database volledig te herstellen als uw toepassing online is tijdens het herstelproces.

• Houd rekening met de extra stappen die nodig zijn om een database te herstellen naar een exemplaar met meerdere replica's, zoals beschreven in Het herstellen van een database naar een exemplaar met meerdere replica's.

• Bepaal welke hulpprogramma's databasebeheerders gebruiken om back-ups te configureren en te herstellen. Voor meer informatie, zie Maak verbinding met een door Azure Arc ingeschakelde SQL-beheerde instantie.

Hoge beschikbaarheid

• Bekijk de beschikbaarheidsvereisten van uw workload en bepaal welke servicelaag het meest geschikt is voor uw implementatie van SQL Managed Instance met Arc:

  • In de servicelaag Algemeen gebruik is er één replica beschikbaar en wordt de hoge beschikbaarheid bereikt via Kubernetes-orkestratie.
  • In de servicelaag Bedrijfskritiek biedt Sql Managed Instance met Azure Arc een ingesloten beschikbaarheidsgroep, naast wat standaard wordt geleverd door Kubernetes-indeling.

• Houd rekening met de mogelijke bedrijfseffecten van downtime in de General Purpose-servicelaag die kan voortvloeien uit het feit dat er slechts één replica bestaat.

• Overweeg hoeveel replica's ( één tot drie) moeten worden geïmplementeerd in de servicelaag Bedrijfskritiek.

• Wanneer u een instantie implementeert in een bedrijfskritieke servicelaag met twee of meer replica's, kunt u de secundaire replica's als leesbaar configureren. Bepaal het aantal secundaire replica's dat moet worden geïmplementeerd in de servicelaag Bedrijfskritiek. Voor meer informatie over het wijzigen van het aantal, zie Leesbare secundaire configureren.

• Beslis over het prioriteren van consistentie over beschikbaarheid via het aantal secundaire replica's dat is vereist voor het doorvoeren van een transactie in de servicelaag Bedrijfskritiek met behulp van de optionele parameter--sync-secondary-to-commit-. Als er verbindingsproblemen zijn tussen de replica's, kan het zijn dat de primaire server geen transacties doorvoert:

  • In een configuratie met twee replica's moet een transactie worden doorgevoerd op beide replica's voor de primaire replica om een succesbericht te ontvangen.
  • In een configuratie met drie replica's moeten ten minste twee van de drie replica's een transactie doorvoeren om een geslaagd bericht te retourneren.

• Bepaal of u een specifieke replica wilt aanwijzen als de primaire replica. Voor meer informatie over het opgeven van een primaire replica, zie voorkeursprimaire replica.

• Bepaal welk Kubernetes-servicetype u gaat gebruiken, LoadBalancer of NodePort. Als u de load balancer gebruikt, kunnen toepassingen opnieuw verbinding maken met hetzelfde primaire eindpunt, waarna Kubernetes de verbinding omleidt naar de nieuwe primaire. Als u de knooppuntpoort gebruikt, moeten toepassingen opnieuw verbinding maken met het nieuwe IP-adres.

Noodherstel

• De exemplaren van sql Managed Instance met Azure Arc in zowel geo-primaire als geo-secundaire sites moeten identiek zijn in rekenkracht en capaciteit, en geïmplementeerd in dezelfde servicelagen.

• Bepaal op een locatie waar de spiegelingscertificaten moeten worden opgeslagen wanneer u de configuratie voor herstel na noodgevallen maakt die toegankelijk is voor beide clusters waarop het exemplaar wordt gehost.

• Overweeg hoe u de downtime van het primaire exemplaar kunt bewaken om te bepalen wanneer een failover naar het secundaire exemplaar moet worden uitgevoerd.

• Elk exemplaar heeft zijn eigen eindpunten. Overweeg hoe uw toepassingen toegang krijgen tot het primaire eindpunt met minimale onderbreking in het geval van failover.

Ontwerpaanaanvelingen

De volgende secties bevatten ontwerpaanbevelingen voor herstel naar een bepaald tijdstip, hoge beschikbaarheid en herstel na noodgevallen.

Herstel op een bepaald moment

• Bij het implementeren van een nieuw exemplaar van sql Managed Instance met Arc, definieert u altijd de -opslagklasse voor back-ups om te voorkomen dat standaard de gegevensopslagklasse wordt gebruikt.

• Gebruik een opslagklasse die ondersteuning biedt voor ReadWriteMany (RWX) voor het back-upvolume. Raadpleeg de opslag disciplines voor een Azure Arc-ingeschakelde SQL Managed Instancevoor richtlijnen.

• Voordat u een herstelbewerking start, gebruikt u optionele parameter--dry-run om eerst te controleren of de bewerking zou slagen. Zie Een database maken vanuit een bepaald tijdstip met behulp van az CLIvoor meer informatie.

• Maak een proces voor het verzenden van back-ups die langere bewaarperioden naar Azure of andere on-premises koude opslag nodig hebben.

• Bewaak de opslag die door uw back-ups wordt gebruikt om te bepalen of u, indien nodig, meer retentie kunt gebruiken.

Hoge beschikbaarheid

• Voer regelmatig analyses uit om de hoge beschikbaarheid van uw exemplaar van SQL Managed Instance met Arc te valideren. Voorbeelden van drills zijn het verwijderen van een pod in een exemplaar voor algemeen gebruik en het mislukken van een replica in een bedrijfskritiek exemplaar.

• Implementeer in de laag Bedrijfskritiek een exemplaar in een configuratie met drie replica's in plaats van een configuratie met twee replica's om bijna nul gegevensverlies te bereiken.

• Voor een betere beschikbaarheid gebruikt u LoadBalancer als het servicetype bij het implementeren van een exemplaar.

• Bekijk de beperkingen voor hoge beschikbaarheid van de Azure Arc-ingeschakelde SQL Managed Instance.

• Bekijk de ondersteunde beschikbaarheidsmodi om te bepalen welke modus moet worden gebruikt op basis van uw behoeften voor hoge beschikbaarheid.

• Wanneer u een bedrijfskritische instantie met meerdere replica's implementeert, gebruikt u een van de secundaire replica's voor Lees--workloads. De verbindingsreeks van uw toepassing moet het secundaire eindpunt opgeven als servicelistener voor omleiding naar de secundaire replica's. Raadpleeg voor meer informatie over het verkrijgen van de primaire en secundaire eindpunten en de AG-status.

• Zie Beheer en bewaking voor SQL Managed Instance met Azure Arcvoor de aanbevolen procedures voor het bewaken van de beschikbaarheid van uw instanties.

Noodherstel

• Zorg ervoor dat uw exemplaren van sql Managed Instance met Arc verschillende namen hebben voor primaire en secundaire sites en dat de waarde voor de gedeelde naam voor de sites identiek is.

• Voer regelmatig noodherstelanalyses uit om het failoverproces te valideren.

• Maak een proces voor het initiëren van zowel handmatige als geforceerde failovers.

• Zie Beheer en bewaking voor Azure Arc-enabled SQL Managed Instanceom de best practices voor het bewaken van de clusters te begrijpen en te weten wanneer een failover nodig is.

• Definieer de DNS-record voor de gedeelde naam van de gedistribueerde beschikbaarheidsgroep op uw DNS-servers om te voorkomen dat u handmatig DNS-records moet maken tijdens de failover.

Volgende stappen

Zie de volgende artikelen voor meer informatie over uw hybride en multicloudtraject:

• Wat zijn gegevensservices met Azure Arc?
• overzicht van : bedrijfscontinuïteit van Azure Arc met SQL Managed Instance
• Kubernetes-validatie van Gegevensservices met Azure Arc
• Uw portfolio beheren voor hybride en multicloudbewerkingen
• Azure Arc-ingeschakelde gegevensservices voor geautomatiseerde scenario's met Azure Arc Jumpstart
• Azure-innovatie overbrengen naar uw hybride omgevingen met Azure Arc, een leertraject van Microsoft Learn