Volumes toevoegen voor een SAP HANA-systeem als dr-systeem met replicatie tussen regio's

Artikel
10/24/2023

In dit artikel wordt beschreven hoe u een toepassingsvolumegroep gebruikt om volumes toe te voegen voor een SAP HANA-systeem als noodherstelsysteem (DR). Deze configuratie maakt gebruik van crr-functionaliteit (Cross-Region Replication) van Azure NetApp Files.

CRR tussen bron- en doel-HANA-servers

Met de functie replicatie in meerdere regio's van Azure NetApp Files kunt u volumes repliceren tussen ondersteunde replicatieparen tussen regio's. Met deze functionaliteit kunt u een volume van een bronregio repliceren naar een volume in de doelregio voor herstel na noodgevallen .

In plaats van HANA System Replication (HSR) te gebruiken, kunt u replicatie tussen regio's gebruiken om een database te beveiligen zonder dat u een HANA-databaseserver nodig hebt die voortdurend wordt uitgevoerd. U moet replicatiedoelvolumes maken in een regio die wordt ondersteund voor replicatie tussen regio's. Toepassingsvolumegroep voor SAP HANA zorgt ervoor dat de doelvolumes worden gemaakt met het juiste volumetype dat voldoet aan alle specifieke SAP HANA-vereisten.

In het volgende diagram ziet u replicatie tussen regio's tussen de bron- en doel-HANA-servers. Replicatie tussen regio's is asynchroon. Daarom hoeven niet alle volumes te worden gerepliceerd.

Diagram that shows cross-region replication between the source and destination HANA servers.

Notitie

Wanneer u een ha-implementatie met HSR aan de primaire kant gebruikt, kunt u ervoor kiezen om niet alleen het primaire HANA-systeem te repliceren, zoals beschreven in deze sectie, maar ook het secundaire HANA-systeem met replicatie tussen regio's. Als u de naamconventie automatisch wilt aanpassen, selecteert u zowel de secundaire HSR- als de bestemmingsopties voor herstel na noodgevallen in het scherm Een volumegroep maken. Het voorvoegsel wordt vervolgens gewijzigd in DR2-.

Belangrijk

Voor het herstellen van de HANA-database in de doelregio moet u toepassingsconsistente opslagmomentopnamen gebruiken voor uw HANA-back-up. U kunt dergelijke momentopnamen maken met behulp van oplossingen voor gegevensbeveiliging, zoals het hulpprogramma Azure-toepassing Consistente momentopname (AzAcSnap).
U moet ten minste het gegevensvolume en het back-upvolume van het logboek repliceren.
U kunt desgewenst het gegevensback-upvolume en het gedeelde volume repliceren.
U moet het logboekvolume nooit repliceren. De toepassingsvolumegroep maakt het logboekvolume als een standaardvolume.

Replicatieschema's, RTO en RPO

De volgende tabel bevat een overzicht van de opties voor het replicatieschema. Ook worden de standaardinstellingen beschreven die worden voorgesteld door de toepassingsvolumegroep:

Volume type	Standaardreplicatieschema	Beschikbare opties	Opmerkingen
Gegevens	Dagelijks	Dagelijks, elk uur	De keuze die u selecteert, heeft invloed op RTO (Recover Time Objective) en de hoeveelheid overgedragen gegevens.
Logboek	-	-	Logboekvolumes worden niet gerepliceerd.
SAP gedeeld	Om de 10 minuten	Elke 10 minuten, elk uur, dagelijks	U moet een schema kiezen op basis van uw SLA-vereisten en de gegevens die zijn opgeslagen in het gedeelde volume.
Gegevensback-up	Dagelijks	Dagelijks, wekelijks	Het repliceren van de gegevensback-upvolumes is optioneel.
Logboekback-up	Om de 10 minuten	Om de 10 minuten	Deze instelling is van invloed op Herstelpuntdoelstelling (RPO).

Het schema voor de replicatiefrequentie heeft gevolgen voor de SLA's:

Time Objective (RTO) herstellen:
De minimale tijd die een herstel zou duren.
Als u wilt herstellen met behulp van de meest recente toepassingsconsistente momentopname, moeten alle beschikbare logboekback-ups opnieuw worden afgespeeld. RTO is afhankelijk van uw back-upfrequentie en de replicatiefrequentie van het gegevensvolume. Als uw back-upfrequentie bijvoorbeeld om de 6 uur is en uw replicatieschema 'Dagelijks' is, kan de oudste back-up 30 uur (24 uur + 6 uur) oud zijn. In dit scenario is het opnieuw afspelen van maximaal 30 uur aan logboekback-ups vereist.
Herstelpuntdoelstelling (RPO):
Het minimale gegevensverlies dat kan optreden.
De frequentie van de SAP HANA-logboekback-up is doorgaans 15 minuten, maar deze instelling kan anders worden geconfigureerd. Uitgaande van een replicatieschema van 10 minuten voor logboekback-ups, is [15+10+transfer_time] het maximale verlies van transacties minuten.

Volumes toevoegen

In het volgende voorbeeld worden volumes toegevoegd aan een SAP HANA-systeem. Het systeem fungeert als een dr-doelsysteem met replicatie tussen regio's.

Selecteer in uw NetApp-account toepassingsvolumegroepen en klik op +Groep toevoegen. Selecteer vervolgens IN Implementatietype SAP HANA en klik op Volgende.
Geef op het tabblad SAP HANA specifieke informatie op.

Belangrijk

Zorg ervoor dat u de bestemmingsoptie voor herstel na noodgevallen selecteert om aan te geven dat u een HANA-systeem maakt als een replicatiebestemming tussen regio's.
- SAP-id (SID):
  De drie alfanumerieke SAP HANA-systeem-id's.
- Groepsnaam:
  De naam van de volumegroep.
- SAP-knooppuntgeheugen:
  Deze waarde definieert de grootte van de SAP HANA-database op de host. Deze wordt gebruikt om de vereiste volumegrootte en doorvoer te berekenen.
- Capaciteitsoverhead (%):
  Wanneer u momentopnamen gebruikt voor gegevensbeveiliging, moet u plannen voor extra capaciteit. In dit veld wordt extra grootte (%) toegevoegd voor het gegevensvolume.
  U kunt deze waarde schatten met behulp van "change rate per day" X "number of days retention".
- Eén host:
  Selecteer deze optie voor een SAP HANA-systeem met één host of de eerste host voor een systeem met meerdere hosts. Alleen de gedeelde, logboekback-up- en gegevensback-upvolumes worden gemaakt met de eerste host.
- Meerdere hosts:
  Selecteer deze optie als u extra hosts toevoegt aan een HANA-systeem met meerdere hosts.
- Bestemming voor herstel na noodgeval:
  Selecteer deze optie om volumes te maken voor een HANA-systeem als dr-site met behulp van replicatie tussen regio's.
  
  Als u de bestemming voor herstel na noodgevallen selecteert, wordt de naamconventie voor de naam van de volumegroep geactiveerd om "-DR-" aan te geven dat er een herstel na noodgevallen is ingesteld.
Klik op Volgende: Volumegroep.
Geef op het tabblad Volumegroep informatie op voor het maken van de volumegroep:
- Nabijheidsplaatsingsgroep (PPG):
  Hiermee geeft u op dat de gegevens en gedeelde volumes moeten worden gemaakt dicht bij de VM's voor herstel na noodgevallen.
  Zelfs als u de VM's niet nodig hebt voor replicatie, moet u ten minste één VIRTUELE machine starten om de PPG te verankeren tijdens het inrichten van de volumes.
- Capaciteitspool:
  Alle volumes worden in één handmatige QoS-capaciteitspool geplaatst.
  Als u de logboekback-up- en gegevensback-upvolumes in een afzonderlijke capaciteitsgroep wilt maken, kunt u ervoor kiezen deze volumes niet toe te voegen aan de volumegroep.
- Virtueel netwerk:
  Geef een bestaand VNet op waarin de VIRTUELE machines worden geplaatst.
- Subnet:
  Geef het gedelegeerde subnet op waar de IP-adressen voor de NFS-exports worden gemaakt. Zorg ervoor dat u een gedelegeerd subnet hebt met voldoende gratis IP-adressen.
Klik op Volgende: Protocollen.
In de sectie Protocollen van het tabblad Volumegroep kunt u het exportbeleid wijzigen. Dit moet gebruikelijk zijn voor alle volumes.

Klik op Volgende: Replicatie.
In de sectie Replicatie van het tabblad Volumegroep wordt het veld Replicatieplanning standaard ingesteld op 'Meerdere' (uitgeschakeld). De standaardreplicatieschema's verschillen voor de gerepliceerde volumes. Als zodanig kunt u de replicatieschema's alleen voor elk volume afzonderlijk wijzigen op het tabblad Volumes en niet globaal voor de hele volumegroep.

Klik op Volgende: Tags.
In de sectie Tags van het tabblad Volumegroep kunt u indien nodig tags toevoegen voor de volumes.

Klik op Volgende: Volumes.
Op het tabblad Volumes wordt de volumelijst weergegeven.

De naamgevingsconventie van het volume bevat een "DR-" voorvoegsel om aan te geven dat de volumes behoren tot de kant van noodherstel (bestemming) van de installatie.

Op het tabblad Volumes wordt ook het volumetype weergegeven:
- DP - Geeft de bestemming aan in de replicatie-instelling voor meerdere regio's. Volumes van dit type zijn niet online, maar in de replicatiemodus.
- RW - Geeft aan dat lees- en schrijfbewerkingen zijn toegestaan.
Het standaardtype voor het logboekvolume is RWen de instelling kan niet worden gewijzigd.

Het standaardtype voor de gegevens, gedeelde en logboekback-upvolumes is DPen de instelling kan niet worden gewijzigd.

Het standaardtype voor het volume van de gegevensback-up is DP, maar deze instelling kan worden gewijzigd in RW.
Klik op elk volume met het DP-type om de bronvolume-id op te geven. Zie De bronvolumeresource-id zoeken voor meer informatie.

U kunt desgewenst het standaardreplicatieschema van een volume wijzigen. Zie Replicatieschema's, RTO en RPO voor de opties voor replicatieplanning.
Nadat u de volumegroep hebt gemaakt, stelt u replicatie in door de instructies te volgen in Replicatie autoriseren vanaf het bronvolume.
1. Kopieer de resource-id van het volume voor elk DP-volume dat u hebt gemaakt.
2. Klik voor elk bronvolume op Replicatie en autoriseren. Plak de resource-id van elk corresponderend doelvolume.

Installatieopties voor het repliceren van een SAP HANA-database met behulp van HANA-systeemreplicatie voor hoge beschikbaarheid

In sommige situaties wilt u mogelijk een hoge beschikbaarheid van HANA-systeemreplicatie combineren met een noodherstelinstallatie (DR) met behulp van replicatie tussen regio's. Afhankelijk van het specifieke gebruikspatroon en de SLA (Service Level Agreement), zijn er twee installatieopties voor replicatie mogelijk. In deze sectie worden de opties beschreven.

Alleen de primaire HANA-databasevolumes repliceren

In dit scenario wijzigt u doorgaans geen rollen voor primaire en secundaire systemen. Een overname gebeurt alleen in een noodgeval. Als zodanig worden de toepassingsconsistente momentopnameback-ups gemaakt die vereist zijn voor replicatie tussen regio's, meestal op de primaire host. Dit is het geval omdat alleen de primaire HANA-database kan worden gebruikt om een back-up te maken.

In het volgende diagram wordt dit scenario beschreven:

In dit scenario moet een dr-installatie alleen de volumes van het primaire HANA-systeem bevatten. Met de dagelijkse replicatie van het primaire gegevensvolume en de logboekback-ups van zowel de primaire als de secundaire systemen kan het systeem worden hersteld op de DR-site. In het diagram wordt één volume gebruikt voor de logboekback-ups van de primaire en secundaire systemen.

In het geval van een overname door de secundaire HSR-host worden de back-ups die in het secundaire systeem worden gemaakt, niet gerepliceerd, maar blijven logboekback-ups van de secundaire host gerepliceerd. Als er zich een noodgeval voordoet, kan het systeem op de DR-site nog steeds worden hersteld met behulp van de oude momentopnameback-up van de voormalige primaire en de gerepliceerde logboekback-ups van beide hosts. RTO neemt toe omdat er meer logboeken moeten worden hersteld, afhankelijk van hoe lang het HSR-paar wordt uitgevoerd in de overnamemodus. Als de overnamemodus aanzienlijk langer is en RTO een probleem wordt, moet u een nieuwe replicatie tussen regio's instellen, inclusief het gegevensvolume van het secundaire systeem.

De werkstroom voor dit scenario is identiek aan de werkstroom Volumes toevoegen.

Zowel primaire als secundaire HANA-databasevolumes repliceren

Om andere redenen dan hoge beschikbaarheid wilt u mogelijk regelmatig schakelen tussen de primaire en secundaire HANA-systemen. In dit scenario moeten toepassingenconsistente back-ups worden gemaakt op beide HANA-hosts.

In het volgende diagram wordt dit scenario beschreven:

In dit scenario wilt u mogelijk beide sets volumes repliceren van de primaire en secundaire HANA-systemen, zoals wordt weergegeven in het diagram.

Als u de volumes voor het secundaire replicatiedoel wilt maken, wordt de naamconventie aangepast. Als u onderscheid wilt maken tussen de replicatie van de primaire en secundaire database, wordt het voorvoegsel gewijzigd van DR in DR2 voor het secundaire HANA-systeem. Behalve deze naamwijziging is de werkstroom identiek aan de werkstroom Volumes toevoegen.

Notitie

Zie voor een gedetailleerde bespreking van een DR-oplossing voor HANA met Azure NetApp Files het technische rapport TR-4891: SAP HANA disaster recovery with Azure NetApp Files. Dit technische rapport bevat gedetailleerde achtergrond en voorbeelden over het gebruik van replicatie tussen regio's voor SAP HANA in Azure NetApp Files.

Delen via