SAP HANA Large Instances hoge beschikbaarheid en herstel na noodherstel in Azure
Belangrijk
Deze documentatie vervangt niet de SAP HANA beheerdocumentatie of SAP-notities. We verwachten dat u ervaring hebt met SAP HANA en bewerkingen, met name met betrekking tot back-up, herstel, hoge beschikbaarheid en herstel na noodherstel.
In dit artikel geven we een overzicht van hoge beschikbaarheid (HA) en noodherstel (DR) van SAP HANA on Azure Large Instances (ook wel bekend als BareMetal Infrastructure). Ook worden enkele vereisten en overwegingen met betrekking tot ha en dr beschreven.
Sommige van de processen die in deze documentatie worden beschreven, zijn vereenvoudigd. Ze zijn niet bedoeld als gedetailleerde stappen die moeten worden opgenomen in bewerkingshandboeken. Als u bewerkingshandboeken voor uw configuraties wilt maken, moet u uw processen uitvoeren en testen met uw specifieke HANA-versies en -releases. Vervolgens kunt u de processen documenteren die specifiek zijn voor uw configuraties.
Ha en DR
Hoge beschikbaarheid en herstel na nood gevallen zijn cruciale aspecten van het uitvoeren van uw bedrijfskritieke SAP HANA op de Azure-server (Large Instances). Het is belangrijk om samen met SAP, uw systeemintegrator of Microsoft de juiste strategieën voor hoge beschikbaarheid en herstel na noodherstel te ontwerpen en te implementeren. Houd ook rekening met de RPO (Recovery Point Objective) en de RTO (Recovery Time Objective), die specifiek zijn voor uw omgeving.
Microsoft ondersteunt enkele 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-zegel in een andere Azure-regio. SAP HANA werkt onafhankelijk van deze methode. Deze functionaliteit is het standaardmechanisme voor herstel na noodherstel 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 regelmatig geminimaliseerd via gegevensreplicatie. SAP HANA ondersteunt asynchrone, synchrone in-memory en synchrone modi. Synchrone modus wordt alleen gebruikt voor SAP HANA systemen binnen hetzelfde datacenter of minder dan 100 km uit elkaar. Met het huidige ontwerp van HANA Large Instance-zegels kan HANA-systeemreplicatie worden gebruikt voor hoge beschikbaarheid binnen slechts één regio. Voor HANA-systeemreplicatie is een externe omgekeerde proxy of routeringscomponent vereist voor configuraties voor herstel na noodherstel in een andere Azure-regio.
- Automatische failover van host: een lokale fouthersteloplossing 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 wordt SAP HANA automatisch overgeslagen naar een stand-byknooppunt.
SAP HANA in Azure (Large Instances) wordt aangeboden in twee Azure-regio's in vier geopolitieke gebieden: VS, Australië, Europa en Japan. Twee regio's binnen een geopolitiek gebied waar HLI-stempels (HANA Large Instance) worden host, zijn verbonden met afzonderlijke toegewezen netwerkcircuits. Deze HLIs worden gebruikt voor het repliceren van opslagmomentopnamen om noodherstelmethoden te bieden. Replicatie is niet standaard ingesteld, maar alleen voor klanten die de functionaliteit voor herstel na noodherstel bestellen. Opslagreplicatie is afhankelijk van het gebruik van opslagmomentopnamen voor grote HANA-exemplaren. U kunt geen Azure-regio kiezen als een DR-regio die zich in een ander geopolitiek gebied.
Momenteel ondersteunde opties
In de volgende tabel ziet u de momenteel ondersteunde methoden en combinaties van hoge beschikbaarheid en herstel na noodherstel:
| Scenario dat wordt ondersteund in HANA Large Instances | Optie voor hoge beschikbaarheid | Optie voor herstel na noodherstel | Opmerkingen |
|---|---|---|---|
| Eén knooppunt | Niet beschikbaar. | Speciale dr-installatie. Multipurpose DR setup. |
|
| Automatische failover van host: uitschalen (met of zonder stand-by) inclusief 1+1 |
Mogelijk met de stand-by met de actieve rol. HANA beheert de rolsschakelaar. |
Speciale dr-installatie. Multipurpose DR setup. 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 wordt verplaatst naar de primaire rol in een failover-case. HANA-systeemreplicatie en failover van besturingssysteembeheer. |
Speciale dr-installatie. Multipurpose DR setup. Dr-synchronisatie met behulp van opslagreplicatie. DR met behulp van HANA-systeemreplicatie is nog niet mogelijk zonder onderdelen van derden. |
Aan elk knooppunt worden afzonderlijke set schijfvolumes gekoppeld. Alleen schijfvolumes van secundaire replica's in de productiesite worden gerepliceerd naar de dr-locatie. Er is één set volumes vereist op de dr-site. |
Een speciale dr-installatie is waar de eenheid HANA Large Instance in de site voor dr-problemen niet wordt gebruikt voor het uitvoeren van een andere workload of een niet-productiesysteem. De eenheid is passief en wordt alleen geïmplementeerd als een nood-failover wordt uitgevoerd. Deze installatie is niet de voorkeursoptie voor de meeste klanten.
Zie Ondersteunde HLI-scenario's voor meer informatie over opslagindeling en ethernetdetails voor uw architectuur.
Notitie
SAP HANA MCOD-implementaties (meerdere HANA-exemplaren in één eenheid) omdat overlayscenario's werken met de ha- en DR-methoden die in de tabel worden vermeld. Een uitzondering hierop is het gebruik van HANA-systeemreplicatie met een automatisch failovercluster op basis van Pacemaker. Een dergelijke case ondersteunt slechts één HANA-exemplaar per eenheid. Voor SAP HANA MDC-implementaties werken alleen niet-opslaggebaseerde ha- en DR-methoden als er meer dan één tenant is geïmplementeerd. Als er één tenant is geïmplementeerd, zijn alle vermelde methoden geldig.
Een multipurpose DR-installatie is waar de eenheid HANA Large Instance op de site voor dr-dr een niet-productieworkload wordt uitgevoerd. Als er sprake is van een noodlott, sluit u het niet-productiesysteem af, bevestigt u de volumesets die door opslag zijn gerepliceerd (toegevoegd) en start u het productie-HANA-exemplaar. De meeste klanten die gebruikmaken van de HANA Large Instance-functionaliteit voor herstel na noodherstel, gebruiken deze configuratie.
In de volgende SAP-artikelen vindt u SAP HANA over hoge beschikbaarheid:
- SAP HANA whitepaper over hoge beschikbaarheid
- SAP HANA Administration Guide
- SAP HANA Academy Video over SAP HANA-systeemreplicatie
- Sap-ondersteuning Opmerking #1999880: veelgestelde vragen over SAP HANA-systeemreplicatie
- SAP-ondersteuning Opmerking #2165547: SAP HANA back-up maken en herstellen in SAP HANA-systeemreplicatieomgeving
- SAP-ondersteuning Opmerking #1984882: gebruik van SAP HANA-systeemreplicatie voor Hardware Exchange met minimale/nul downtime
Netwerkoverwegingen voor herstel na nood gevallen met grote HANA-exemplaren
Als u wilt profiteren van de functionaliteit voor herstel na nood gevallen van grote HANA-exemplaren, moet u netwerkconnectiviteit met de twee Azure-regio's ontwerpen. U hebt een Azure ExpressRoute on-premises circuitverbinding nodig in uw Azure-hoofdregio en een andere circuitverbinding van on-premises naar uw regio voor herstel na noodherstel. Deze meting heeft betrekking op een situatie waarin zich een probleem voordeed in een Azure-regio, met inbegrip van een MSEE-locatie (Microsoft Enterprise Edge Router).
U kunt ook alle virtuele Azure-netwerken die verbinding maken met SAP HANA in 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 andersom. Deze meting is een geval waarbij 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 noodherstelscenario's:
Andere vereisten met opslagreplicatie van grote HANA-exemplaren voor herstel na nood gevallen
- Bestelt SAP HANA Azure-SKU's (Large Instances) van dezelfde grootte als uw productie-SKU's en implementeer deze in de regio voor herstel na noodherstel. In huidige klantimplementaties worden deze exemplaren gebruikt om niet-productie-HANA-exemplaren uit te voeren. Deze configuraties worden aangeduid als multipurpose DR setups.
- Bestelt meer opslag op de site voor herstel na noodherstel voor elk van uw SAP HANA op Azure-SKU's (large instances) die u wilt herstellen op de site voor herstel na noodherstel. Als u meer opslag koopt, kunt u de opslagvolumes toewijzen. U kunt de volumes die het doel zijn van de opslagreplicatie van uw Azure-productieregio toewijzen aan de Azure-regio voor herstel na noodherstel.
- Mogelijk hebt u SAP HANA systeemreplicatie ingesteld op de primaire en opslagreplicatie naar de DR-site. Vervolgens moet u meer opslagruimte aanschaffen op de site voor dr-replicatie, 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.