Principes en voorbereiding voor herstel na noodgevallen

In dit artikel bespreken we belangrijke principes voor herstel na noodgevallen (DR) voor HANA Large Instances (ook wel bekend als BareMetal Infrastructure). We doorlopen de stappen die u moet uitvoeren ter voorbereiding op herstel na noodgevallen. U ziet ook hoe u uw beoogde hersteltijd (RTO) en RPO (Recovery Point Objective) kunt bereiken in een noodgeval.

DR-principes voor HANA Large Instances

HANA Large Instances bieden functionaliteit voor herstel na noodgevallen tussen HANA Large Instance-stempels in verschillende Azure-regio's. Stel dat u HANA Large Instances implementeert in de regio US - west van Azure. Vervolgens kunt u de HANA Large Instances in de regio US - oost gebruiken als eenheden voor herstel na noodgevallen. Herstel na noodgevallen wordt niet automatisch geconfigureerd, omdat u hiervoor moet betalen voor een andere grote HANA-instantie in de dr-regio. De instelling voor herstel na noodgevallen werkt voor instellingen voor omhoog schalen en uitschalen.

De meeste klanten gebruiken de eenheid in de DR-regio om niet-productiesystemen uit te voeren die gebruikmaken van een geïnstalleerd HANA-exemplaar. De grote HANA-instantie moet van dezelfde SKU zijn als de SKU die voor productiedoeleinden wordt gebruikt. In de volgende afbeelding ziet u hoe de schijfconfiguratie tussen de servereenheid in de Azure-productieregio en de regio voor herstel na noodgevallen eruitziet:

Zoals wordt weergegeven in deze overzichtsafbeelding, moet u een tweede set schijfvolumes bestellen. De doelschijfvolumes die zijn gekoppeld aan de HANA Large Instance-server in de DR-site, hebben dezelfde grootte als de productievolumes.

De volgende volumes worden gerepliceerd van de productieregio naar de DR-site:

• /hana/data
• /hana/logbackups
• /hana/shared (inclusief /usr/sap)

Het volume /hana/log wordt niet gerepliceerd. Het SAP HANA-transactielogboek is niet nodig bij het herstellen van deze volumes.

Opslagreplicatie van grote HANA-exemplaren

De basis van de DR-functionaliteit in de infrastructuur van grote HANA-exemplaren is de opslagreplicatie. De functionaliteit die aan de opslagzijde wordt gebruikt, is geen constante stroom wijzigingen die op een asynchrone manier worden gerepliceerd als er wijzigingen plaatsvinden in het opslagvolume. In plaats daarvan is het een mechanisme dat afhankelijk is van het regelmatig maken van momentopnamen van deze volumes. Het verschil tussen een al gerepliceerde momentopname en een nieuwe momentopname die nog niet is gerepliceerd, wordt vervolgens overgebracht naar de DR-site naar de doelschijfvolumes. Deze momentopnamen worden opgeslagen op de volumes. Als er een failover voor herstel na noodgevallen is, moeten deze worden hersteld op die volumes.

De eerste overdracht van de volledige gegevens van het volume moet plaatsvinden voordat de hoeveelheid gegevens kleiner wordt dan de verschillen tussen momentopnamen. Vervolgens bevatten de volumes op de DR-site alle momentopnamen van het volume die in de productiesite zijn gemaakt. Uiteindelijk kunt u dat DR-systeem gebruiken om naar een eerdere status te gaan om verloren gegevens te herstellen, zonder het productiesysteem terug te draaien.

Als er een MCOD-implementatie is met meerdere onafhankelijke SAP HANA-exemplaren op één grote HANA-instantie, moet voor alle SAP HANA-exemplaren opslag worden gerepliceerd naar de dr-zijde.

Wanneer u HANA-systeemreplicatie gebruikt voor hoge beschikbaarheid in uw productiesite en u replicatie op basis van opslag gebruikt voor de DR-site, worden de volumes van beide knooppunten van de primaire site naar het DR-exemplaar gerepliceerd. Koop extra opslag (dezelfde grootte als het primaire knooppunt) op de dr-site om replicatie van zowel primaire als secundaire knooppunten naar de hersteloplossing mogelijk te maken.

Notitie

De HANA-functie voor opslagreplicatie voor grote exemplaren spiegelt en repliceert momentopnamen van opslag. Als u geen momentopnamen van opslag maakt zoals beschreven in Back-up maken en herstellen, kan er geen replicatie naar de herstelherstelsite plaatsvinden. Uitvoering van opslagmomentopnamen is een vereiste voor opslagreplicatie naar de site voor herstel na noodgevallen.

Voorbereiding van het scenario voor herstel na noodgevallen

In dit scenario voor herstel na noodgeval hebt u een productiesysteem dat wordt uitgevoerd op grote HANA-exemplaren in de Azure-productieregio. Voor de volgende stappen stellen we dat de SID van dat HANA-systeem 'PRD' is. U hebt ook een niet-productiesysteem dat wordt uitgevoerd op HANA Large Instances in de Azure-regio voor herstel na noodgeval. De SID is 'TST'. In de volgende afbeelding ziet u deze configuratie:

Stel dat het serverexemplaar nog niet is besteld met de extra opslagvolumeset. Vervolgens koppelt SAP HANA in Azure Service Management de toegevoegde volumes. Ze zijn een doel voor de productiereplica naar het grote HANA-exemplaar waarop u het TST HANA-exemplaar uitvoert. U moet de SID van uw productie-HANA-exemplaar opgeven. Nadat SAP HANA in Azure Service Management de bijlage van deze volumes heeft bevestigd, moet u deze volumes koppelen aan de grote instantie van HANA.

In de volgende stap installeert u het tweede SAP HANA-exemplaar op de grote HANA-instantie in de DR Azure-regio waar u het TST HANA-exemplaar uitvoert. Het zojuist geïnstalleerde SAP HANA-exemplaar moet dezelfde SID hebben. De gebruikers die zijn gemaakt, moeten dezelfde UID en groeps-id hebben als het productie-exemplaar. Lees Back-up maken en herstellen voor meer informatie. Als de installatie is geslaagd, moet u het volgende doen:

• Voer stap 2 van de opslagmomentopnamevoorbereiding uit die wordt beschreven in Back-up maken en herstellen.
• Maak een openbare sleutel voor de DR-eenheid van de HANA Large Instance als u dit nog niet hebt gedaan. Zie stap 3 van de opslagmomentopnamevoorbereiding die wordt beschreven in Back-up maken en herstellen.
• Onderhoud de HANABackupCustomerDetails.txt met het nieuwe HANA-exemplaar en test of de connectiviteit met de opslag correct werkt.
• Stop het zojuist geïnstalleerde SAP HANA-exemplaar op de grote HANA-instantie in de REGIO DR Azure.
• Ontkoppel deze PRD-volumes en neem contact op met SAP HANA in Azure Service Management. De volumes kunnen niet gekoppeld blijven aan de eenheid omdat ze niet toegankelijk zijn terwijl ze functioneren als het opslagreplicatiedoel.

Het operationele team stelt de replicatierelatie vast tussen de PRD-volumes in de productieregio en de PRD-volumes in de DR-regio.

Belangrijk

Het volume /hana/log wordt niet gerepliceerd omdat het niet nodig is om de gerepliceerde SAP HANA-database te herstellen naar een consistente status op de site voor herstel na noodgevallen.

Stel vervolgens het back-upschema voor opslagmomentopnamen in om uw RTO en RPO te bereiken als er zich een noodgeval voordoet. Als u de RPO wilt minimaliseren, stelt u de volgende replicatie-intervallen in de HANA Large Instance-service in:

• Voor de volumes die worden gedekt door de gecombineerde momentopname (momentopnametype hana), stelt u in om elke 15 minuten te repliceren naar de equivalente opslagvolumedoelen op de site voor herstel na noodgevallen.
• Voor het back-upvolume van het transactielogboek ( logboeken van het momentopnametype) stelt u in op elke 3 minuten te repliceren naar de equivalente opslagvolumedoelen in de site voor herstel na noodgevallen.

De RPO minimaliseren:

• Maak elke 30 minuten tot 1 uur een momentopname van het type hana . Zie Back-up maken met Azure-toepassing hulpprogramma voor consistente momentopnamen voor meer informatie.
• Maak elke 5 minuten back-ups van sap HANA-transactielogboeken.
• Maak elke 5-15 minuten een momentopname van het type opslag. Met deze intervalperiode bereikt u een RPO van ongeveer 15-25 minuten.

Met deze installatie kan de volgorde van back-ups van transactielogboeken, opslagmomentopnamen en de replicatie van het back-upvolume van het HANA-transactielogboek en /hana/data, en /hana/shared (inclusief /usr/sap) eruitzien als de gegevens in deze afbeelding:

Als u een nog betere RPO wilt bereiken in het geval van herstel na noodgevallen, kunt u de back-ups van het HANA-transactielogboek van SAP HANA on Azure (Large Instances) kopiëren naar de andere Azure-regio. Voer de volgende stappen uit om deze verdere RPO-reductie te bereiken:

1. Maak zo vaak mogelijk een back-up van het HANA-transactielogboek naar /hana/logbackups.
2. Gebruik rsync om de back-ups van het transactielogboek te kopiëren naar de NFS-share-gehoste Azure-vm's. De virtuele machines (VM's) bevinden zich in virtuele Azure-netwerken in de Azure-productieregio en in de regio herstel na noodgeval. Verbind beide virtuele Azure-netwerken met het circuit dat de productie-HANA Large Instances verbindt met Azure. Zie Netwerkoverwegingen voor herstel na noodgevallen met HANA Large Instances voor meer informatie.
3. Bewaar de back-ups van het transactielogboek in de regio van de VM die is gekoppeld aan de geëxporteerde NFS-opslag.
4. In een noodfailover moet u de back-ups van het transactielogboek die u op het volume /hana/logbackups vindt, aanvullen met recenter genomen back-ups van transactielogboeken op de NFS-share in de DR-site.
5. Start een back-up van een transactielogboek om te herstellen naar de meest recente back-up die mogelijk is opgeslagen in de regio voor herstel na noodgeval.

Wanneer HANA Large Instance-bewerkingen de configuratie van de replicatierelatie bevestigen en u de back-ups van de opslagmomentopnamen voor de uitvoering start, wordt de gegevensreplicatie gestart.

Naarmate de replicatie vordert, worden de momentopnamen op de PRD-volumes in de Dr. Azure-regio's niet hersteld. De momentopnamen worden alleen opgeslagen. Als de volumes in een dergelijke status zijn gekoppeld, vertegenwoordigen ze de status waarin u deze volumes hebt ontkoppeld nadat het PRD SAP HANA-exemplaar is geïnstalleerd op de server in de Dr. Azure-regio. Ze vertegenwoordigen ook de opslagback-ups die nog niet zijn hersteld.

Als er een failover is, kunt u er ook voor kiezen om te herstellen naar een oudere opslagmomentopname in plaats van naar de meest recente opslagmomentopname.

Volgende stappen

Meer informatie over de failoverprocedure voor herstel na noodgevallen.

Procedure bij failover van het noodherstel