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 wordt een van de secundaire exemplaren gepromoveerd naar de primaire instantie en krijgt het zojuist gepromoveerde exemplaar lees-schrijfverkeer 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 en herstel na noodgevallen om het effect van SQL Managed Instance met Azure Arc te beoordelen op uw algemene BCDR-model. 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 zijn 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 moet worden gebruikt voor het permanente volume voor back-ups. Zie Storage-disciplines voor Sql Managed Instance met Azure Arc.

• 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 opslagdisciplines voor SQL Managed Instance met Azure Arc voor 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.

• Let op dat herstel naar een bepaald 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 op een exemplaar met meerdere replica's.

• Bepaal welke hulpprogramma's databasebeheerders gebruiken om back-ups te configureren en te herstellen. Zie Verbinding maken met sql Managed Instance met Azure Arc voor meer informatie.

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-indeling.
  • In de Bedrijfskritiek-servicelaag biedt Sql Managed Instance met Azure Arc een ingesloten beschikbaarheidsgroep, naast wat systeemeigen wordt geleverd door Kubernetes-indeling.

• Houd rekening met de mogelijke bedrijfseffecten van downtime in de servicelaag Algemeen gebruik die kan leiden tot het bestaan van slechts één replica.

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

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

• 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 Bedrijfskritiek servicelaag 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. Zie Voorkeursreplica voor meer informatie over het opgeven van een primaire 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.

Herstel na noodgeval

• 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 naar een bepaald tijdstip

• 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 de standaardinstelling voor de gegevensopslagklasse wordt gebruikt.

• Gebruik een opslagklasse die ReadWriteMany (RWX) ondersteunt voor het back-upvolume. Zie de opslagdisciplines voor Sql Managed Instance met Azure Arc voor hulp.

• Voordat u een herstelbewerking start, gebruikt u de 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 CLI voor 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 Bedrijfskritiek-laag 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 sql Managed Instance met Azure Arc.

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

• Wanneer u een Bedrijfskritiek exemplaar met meerdere replica's implementeert, gebruikt u een van de secundaire replica's voor leesworkloads. Uw toepassing verbindingsreeks moet het secundaire eindpunt opgeven als servicelistener voor omleiding naar de secundaire replica's. Zie De primaire en secundaire eindpunten en ag-status ophalen voor meer informatie over eindpunten.

• Zie Beheer en bewaking voor sql Managed Instance met Azure Arc voor meer informatie over de aanbevolen procedures voor het bewaken van de beschikbaarheid van uw exemplaren.

Herstel na noodgeval

• 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 SQL Managed Instance met Azure Arc om inzicht te hebben in de best practices voor het bewaken van de status van de clusters en om te begrijpen wanneer een failover is vereist.

• 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 multicloudcloudcloudtraject:

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