Hög tillgänglighet och haveriberedskap för SAP HANA stora instanser i Azure

Viktigt

Den här dokumentationen ersätter inte SAP HANA-administrationsdokumentationen eller SAP Notes. Vi förväntar oss att du har expertis inom SAP HANA-administration och -åtgärder, särskilt när det gäller säkerhetskopiering, återställning, hög tillgänglighet och haveriberedskap.

I den här artikeln ger vi en översikt över hög tillgänglighet (HA) och haveriberedskap (DR) för SAP HANA på stora Azure-instanser (även kallat BareMetal Infrastructure). Vi kommer också att beskriva några av de krav och överväganden som rör HA och DR.

Vissa av de processer som beskrivs i den här dokumentationen är förenklade. De är inte avsedda som detaljerade steg som ska ingå i handböcker för åtgärder. Om du vill skapa handböcker för dina konfigurationer kör och testar du dina processer med dina specifika HANA-versioner och -versioner. Du kan sedan dokumentera de processer som är specifika för dina konfigurationer.

HA och DR

Hög tillgänglighet och haveriberedskap är viktiga aspekter av att köra din verksamhetskritiska SAP HANA på Azure-servern (stora instanser). Det är viktigt att arbeta med SAP, din systemintegrerare eller Microsoft för att utforma och implementera rätt strategier för hög tillgänglighet och haveriberedskap. Tänk också på mål för återställningspunkt (RPO) och mål för återställningstid (RTO), som är specifika för din miljö.

Microsoft har stöd för vissa funktioner för hög tillgänglighet för SAP HANA med STORA HANA-instanser. Dessa funktioner är:

  • Lagringsreplikering: Lagringssystemets möjlighet att replikera alla data till en annan HANA Large Instance-stämpel i en annan Azure-region. SAP HANA fungerar oberoende av den här metoden. Den här funktionen är standardmekanismen för haveriberedskap som erbjuds för STORA HANA-instanser.
  • HANA-systemreplikering: Replikering av alla data i SAP HANA till ett separat SAP HANA-system. RTO minimeras med hjälp av datareplikering med jämna mellanrum. SAP HANA stöder asynkrona, synkrona minnesbaserade och synkrona lägen. Synkront läge används endast för SAP HANA-system i samma datacenter eller mindre än 100 km från varandra. Med den aktuella designen av HANA Large Instance-stämplar kan HANA-systemreplikering endast användas för hög tillgänglighet inom en region. HANA-systemreplikering kräver en omvänd proxy eller routningskomponent från tredje part för haveriberedskapskonfigurationer till en annan Azure-region.
  • Värd för automatisk redundans: En lokal felåterställningslösning för SAP HANA som är ett alternativ till HANA-systemreplikering. Om den primära noden blir otillgänglig konfigurerar du en eller flera SAP HANA-noder i utskalningsläge och SAP HANA redundansväxlar automatiskt till en väntelägesnod.

SAP HANA på Azure (stora instanser) erbjuds i två Azure-regioner inom fyra geopolitiska områden: USA, Australien, Europa och Japan. Två regioner inom ett geopolitiskt område som är värd för HLI-stämplar (HANA Large Instance) är anslutna till separata dedikerade nätverkskretsar. Dessa HLIs används för att replikera ögonblicksbilder av lagring för att tillhandahålla haveriberedskapsmetoder. Replikering konfigureras inte som standard, utan endast för kunder som beställer funktioner för haveriberedskap. Lagringsreplikering är beroende av användningen av ögonblicksbilder av lagring för STORA HANA-instanser. Du kan inte välja en Azure-region som en DR-region som finns i ett annat geopolitiskt område.

Alternativ som stöds för närvarande

I följande tabell visas de metoder och kombinationer för hög tillgänglighet och haveriberedskap som stöds för närvarande:

Scenario som stöds i stora HANA-instanser Alternativ för hög tillgänglighet Alternativ för haveriberedskap Kommentarer
Enkel nod Inte tillgängligt. Dedikerad DR-installation.
Installation av flerfunktions-DR.
Värd för automatisk redundans: Utskalning (med eller utan vänteläge)
inklusive 1+1
Möjligt med vänteläge som tar den aktiva rollen.
HANA styr rollväxeln.
Dedikerad DR-installation.
Installation av flerfunktions-DR.
DR-synkronisering med hjälp av lagringsreplikering.
HANA-volymuppsättningar är anslutna till alla noder.
DR-platsen måste ha samma antal noder.
HANA-systemreplikering Möjligt med primär eller sekundär konfiguration.
Sekundär flyttar till primär roll i ett redundansfall.
HANA-systemreplikering och redundansväxling av operativsystemkontroll.
Dedikerad DR-installation.
Installation av flerfunktions-DR.
DR-synkronisering med hjälp av lagringsreplikering.
DR med hjälp av HANA-systemreplikering är ännu inte möjligt utan komponenter från tredje part.
En separat uppsättning diskvolymer är anslutna till varje nod.
Endast diskvolymer för den sekundära repliken på produktionsplatsen replikeras till dr-platsen.
En uppsättning volymer krävs på dr-platsen.

En dedikerad DR-installation är där enheten HANA Large Instance på DR-platsen inte används för att köra andra arbetsbelastningar eller icke-produktionssystem. Enheten är passiv och distribueras endast om en haveriberedskap körs. Den här konfigurationen är inte det föredragna alternativet för de flesta kunder.

Mer information om lagringslayout och Ethernet-information för din arkitektur finns i HLI-scenarier som stöds.

Anteckning

Före HANA2.0 SPS4 hade det inte stöd för att ta databasögonblicksbilder av containerdatabaser för flera klientorganisationer (fler än en klientorganisation). Med SPS4 och nyare HAR SAP fullt stöd för den här ögonblicksbildsfunktionen.

En dr-installation med flera funktioner är där enheten HANA Large Instance på DR-platsen kör en icke-produktionsarbetsbelastning. Om det uppstår en katastrof stänger du av icke-produktionssystemet, monterar de lagringsreeplikerade (tillagda) volymuppsättningarna och startar HANA-produktionsinstansen. De flesta kunder som använder haveriberedskapsfunktionen för hana-stora instanser använder den här konfigurationen.

Mer information om hög tillgänglighet för SAP HANA finns i följande SAP-artiklar:

Nätverksöverväganden för haveriberedskap med STORA HANA-instanser

Om du vill dra nytta av funktionerna för haveriberedskap i STORA HANA-instanser måste du utforma nätverksanslutningen till de två Azure-regionerna. Du behöver en Azure ExpressRoute-kretsanslutning från din lokala plats i din huvudsakliga Azure-region och en annan kretsanslutning från en lokal plats till din haveriberedskapsregion. Det här måttet omfattar en situation där det finns ett problem i en Azure-region, inklusive en MsEE-plats (Microsoft Enterprise Edge Router).

Du kan också ansluta alla virtuella Azure-nätverk som ansluter till SAP HANA på Azure (stora instanser) i en region till en ExpressRoute-krets som ansluter STORA HANA-instanser i den andra regionen. Med den här korsanslutningen kan tjänster som körs i ett virtuellt Azure-nätverk i region 1 ansluta till HANA Large Instance-enheter i region 2 och tvärtom. Det här måttet åtgärdar ett fall där endast en av de MSEE-platser som ansluter till din lokala plats med Azure går offline.

Följande bild illustrerar en elastisk konfiguration för haveriberedskapsfall:

Optimal konfiguration för haveriberedskap

Andra krav med HANA Large Instances-lagringsreplikering för haveriberedskap

  • Beställ SKU:er för SAP HANA på Azure (stora instanser) av samma storlek som dina produktions-SKU:er och distribuera dem i haveriberedskapsregionen. I aktuella kunddistributioner används dessa instanser för att köra HANA-instanser som inte är produktionsbaserade. Dessa konfigurationer kallas för dr-installationer med flera funktioner.
  • Beställ mer lagringsutrymme på dr-platsen för var och en av dina SAP HANA på Azure (stora instanser) SKU:er som du vill återställa på haveriberedskapsplatsen. Genom att köpa mer lagringsutrymme kan du allokera lagringsvolymerna. Du kan allokera de volymer som är målet för lagringsreplikeringen från din Azure-produktionsregion till Azure-regionen för haveriberedskap.
  • Du kan ha konfigurerat SAP HANA-systemreplikering för primär och lagringsbaserad replikering till DR-platsen. Sedan måste du köpa mer lagringsutrymme på dr-platsen så att data för både primära och sekundära noder replikeras till DR-platsen.

Nästa steg

Läs mer om säkerhetskopiering och återställning av SAP HANA på stora HANA-instanser.