Hoge beschikbaarheid en herstel na noodgevallen van SAP HANA Large Instances in Azure
Belangrijk
Deze documentatie vervangt niet de SAP HANA-beheerdocumentatie of SAP-notities. We verwachten dat u expertise hebt op het gebied van SAP HANA-beheer en -bewerkingen, met name met betrekking tot de onderwerpen back-up, herstel, hoge beschikbaarheid en herstel na noodgevallen.
In dit artikel geven we een overzicht van hoge beschikbaarheid (HA) en noodherstel (DR) van SAP HANA on Azure Large Instances (ook wel BareMetal Infrastructure genoemd). We zullen ook enkele van de vereisten en overwegingen met betrekking tot hoge beschikbaarheid en herstel na noodgevallen beschrijven.
Sommige van de processen die in deze documentatie worden beschreven, zijn vereenvoudigd. Ze zijn niet bedoeld als gedetailleerde stappen die moeten worden opgenomen in bedieningshandboeken. Als u bedieningshandboeken voor uw configuraties wilt maken, voert u uw processen uit en test u deze met uw specifieke HANA-versies en -releases. Vervolgens kunt u de processen die specifiek zijn voor uw configuraties documenteert.
Hoge beschikbaarheid en herstel na noodgevallen
Hoge beschikbaarheid en herstel na noodgevallen zijn cruciale aspecten van het uitvoeren van uw bedrijfskritische SAP HANA op de Azure-server (large instances). Het is belangrijk om samen te werken met SAP, uw systeemintegrator of Microsoft om de juiste strategieën voor hoge beschikbaarheid en herstel na noodgevallen goed te ontwerpen en te implementeren. Houd ook rekening met de recovery point objective (RPO) en recovery time objective (RTO), die specifiek zijn voor uw omgeving.
Microsoft ondersteunt sommige sap HANA-mogelijkheden voor hoge beschikbaarheid met HANA Large Instances. Deze mogelijkheden omvatten:
- Opslagreplicatie: de mogelijkheid van het opslagsysteem om alle gegevens te repliceren naar een andere HANA Large Instance-stempel in een andere Azure-regio. SAP HANA werkt onafhankelijk van deze methode. Deze functionaliteit is het standaardmechanisme voor herstel na noodgevallen dat wordt aangeboden voor grote HANA-exemplaren.
- HANA-systeemreplicatie: de replicatie van alle gegevens in SAP HANA naar een afzonderlijk SAP HANA-systeem. De RTO wordt geminimaliseerd door middel van gegevensreplicatie met regelmatige tussenpozen. SAP HANA ondersteunt asynchrone, synchrone in-memory en synchrone modi. De synchrone modus wordt alleen gebruikt voor SAP HANA-systemen binnen hetzelfde datacenter of op minder dan 100 km afstand. Met het huidige ontwerp van HANA Large Instance-stempels kan HANA-systeemreplicatie worden gebruikt voor hoge beschikbaarheid binnen slechts één regio. Voor HANA-systeemreplicatie is een omgekeerde proxy of routeringsonderdeel van derden vereist voor configuraties voor herstel na noodgevallen naar een andere Azure-regio.
- Automatische failover van host: een lokale oplossing voor foutherstel voor SAP HANA die een alternatief is voor HANA-systeemreplicatie. Als het primaire knooppunt niet meer beschikbaar is, configureert u een of meer stand-by SAP HANA-knooppunten in de uitschaalmodus en voert SAP HANA automatisch een failover uit naar een stand-byknooppunt.
SAP HANA on Azure (Large Instances) wordt aangeboden in twee Azure-regio's in vier geopolitieke gebieden: de VS, Australië, Europa en Japan. Twee regio's binnen een geopolitiek gebied waar HLI-stempels (Large Instance) van HANA worden gehost, zijn verbonden met afzonderlijke toegewezen netwerkcircuits. Deze HLI's worden gebruikt voor het repliceren van opslagmomentopnamen om herstelmethoden na noodgevallen te bieden. Replicatie is niet standaard ingesteld, maar alleen voor klanten die noodherstelfunctionaliteit bestellen. Opslagreplicatie is afhankelijk van het gebruik van opslagmomentopnamen voor HANA Large Instances. U kunt geen Azure-regio kiezen als dr-regio die zich in een ander geopolitieke gebied bevindt.
Momenteel ondersteunde opties
In de volgende tabel ziet u de momenteel ondersteunde methoden en combinaties voor hoge beschikbaarheid en herstel na noodgevallen:
Scenario ondersteund in HANA Large Instances | Optie voor hoge beschikbaarheid | Optie voor herstel na noodgeval | Opmerkingen |
---|---|---|---|
Eén knooppunt | Niet beschikbaar. | Toegewezen dr-installatie. Multifunctionele dr-installatie. |
|
Automatische failover hosten: uitschalen (met of zonder stand-by) inclusief 1+1 |
Mogelijk met de stand-by die de actieve rol neemt. HANA bepaalt de rolwisseling. |
Toegewezen dr-installatie. Multifunctionele dr-installatie. DR-synchronisatie met behulp van opslagreplicatie. |
HANA-volumesets zijn gekoppeld aan alle knooppunten. Dr-site moet hetzelfde aantal knooppunten hebben. |
HANA-systeemreplicatie | Mogelijk met primaire of secundaire installatie. Secundaire verplaatsingen naar primaire rol in een failover-case. Failover van HANA-systeemreplicatie en besturingssysteembeheer. |
Toegewezen dr-installatie. Multifunctionele dr-installatie. DR-synchronisatie met behulp van opslagreplicatie. DR met behulp van HANA-systeemreplicatie is nog niet mogelijk zonder onderdelen van derden. |
Aan elk knooppunt wordt een afzonderlijke set schijfvolumes gekoppeld. Alleen schijfvolumes van secundaire replica in de productiesite worden gerepliceerd naar de dr-locatie. Er is één set volumes vereist op de dr-site. |
Een toegewezen dr-installatie is waar de HANA Large Instance-eenheid in de DR-site niet wordt gebruikt voor het uitvoeren van een andere workload of niet-productiesysteem. De eenheid is passief en wordt alleen geïmplementeerd als er een noodfailover wordt uitgevoerd. Deze installatie is niet de voorkeursoptie voor de meeste klanten.
Zie Scenario's die door HLI worden ondersteund voor meer informatie over de opslagindeling en Ethernet-details voor uw architectuur.
Notitie
Vóór HANA2.0 SPS4 werd het niet ondersteund om databasemomentopnamen te maken van databasecontainerdatabases met meerdere tenants (meer dan één tenant). Met SPS4 en nieuwer ondersteunt SAP deze momentopnamefunctie volledig.
Een multifunctionele dr-installatie is waar de HANA Large Instance-eenheid op de DR-site een niet-productieworkload uitvoert. Als er een noodgeval is, sluit u het niet-productiesysteem af, koppelt u de met opslag gerepliceerde (toegevoegde) volumesets en start u het productie-HANA-exemplaar. De meeste klanten die gebruikmaken van de functionaliteit voor herstel na noodgevallen van HANA Large Instance gebruiken deze configuratie.
Meer informatie over hoge beschikbaarheid van SAP HANA vindt u in de volgende SAP-artikelen:
- Technisch document over hoge beschikbaarheid van SAP HANA
- SAP HANA-beheerhandleiding
- SAP HANA Academy-video over SAP HANA-systeemreplicatie
- Sap-ondersteuningsoptekening #1999880 : veelgestelde vragen over SAP HANA-systeemreplicatie
- SAP-ondersteuningsoptekening #2165547 : back-up en herstel van SAP HANA in de SAP HANA-systeemreplicatieomgeving
- Sap-ondersteuningsnotitie #1984882 : SAP HANA-systeemreplicatie gebruiken voor Hardware Exchange met minimale/nul downtime
Netwerkoverwegingen voor herstel na noodgevallen met HANA Large Instances
Als u wilt profiteren van de functionaliteit voor herstel na noodgevallen van HANA Large Instances, moet u netwerkconnectiviteit met de twee Azure-regio's ontwerpen. U hebt een Azure ExpressRoute-circuitverbinding nodig van on-premises in uw azure-hoofdregio en een andere circuitverbinding van on-premises naar uw regio voor herstel na noodgevallen. Deze meting heeft betrekking op een situatie waarin er een probleem is in een Azure-regio, waaronder een Microsoft Enterprise Edge Router (MSEE)-locatie.
U kunt ook alle virtuele Azure-netwerken die verbinding maken met SAP HANA on Azure (large instances) in de ene regio verbinden met een ExpressRoute-circuit dat HANA Large Instances in de andere regio verbindt. Met deze cross-connect kunnen services die worden uitgevoerd op een virtueel Azure-netwerk in regio 1 verbinding maken met HANA Large Instance-eenheden in regio 2 en omgekeerd. Deze meting heeft betrekking op een geval waarin slechts één van de MSEE-locaties die verbinding maakt met uw on-premises locatie met Azure offline gaat.
In de volgende afbeelding ziet u een flexibele configuratie voor herstel na noodgevallen:
Andere vereisten met opslagreplicatie van HANA Large Instances voor herstel na noodgevallen
- Bestel SAP HANA on Azure (Large Instances) SKU's van dezelfde grootte als uw productie-SKU's en implementeer deze in de regio voor herstel na noodgevallen. In huidige klantimplementaties worden deze exemplaren gebruikt om niet-productie-HANA-exemplaren uit te voeren. Deze configuraties worden multifunctionele DR-instellingen genoemd.
- Bestel meer opslag op de DR-site voor elk van uw SAP HANA on Azure-SKU's (large instances) die u wilt herstellen op de site voor herstel na noodgevallen. Als u meer opslagruimte koopt, kunt u de opslagvolumes toewijzen. U kunt de volumes die het doel zijn van de opslagreplicatie van uw productie-Azure-regio toewijzen aan de Azure-regio voor herstel na noodgevallen.
- Mogelijk hebt u SAP HANA-systeemreplicatie ingesteld voor primaire replicatie en replicatie op basis van opslag naar de DR-site. Vervolgens moet u meer opslag aanschaffen op de dr-site, zodat de gegevens van zowel primaire als secundaire knooppunten worden gerepliceerd naar de DR-site.
Volgende stappen
Meer informatie over back-up en herstel van SAP HANA op grote HANA-exemplaren.