SAP HANA-tillgänglighet i Azure-regioner
I den här artikeln beskrivs scenarier som rör SAP HANA-tillgänglighet i olika Azure-regioner. På grund av avståndet mellan Azure-regioner innebär det särskilda överväganden att konfigurera SAP HANA-tillgänglighet i flera Azure-regioner.
Varför distribuera över flera Azure-regioner
Azure-regioner avgränsas ofta med stora avstånd. Beroende på den geopolitiska regionen kan avståndet mellan Azure-regioner vara hundratals mil, eller till och med flera tusen miles, som i USA. På grund av avståndet får nätverkstrafik mellan tillgångar som distribueras i två olika Azure-regioner betydande svarstid för nätverksrunda. Svarstiden är tillräckligt stor för att undanta synkront datautbyte mellan två SAP HANA-instanser under typiska SAP-arbetsbelastningar.
Å andra sidan har organisationer ofta ett avståndskrav mellan platsen för det primära datacentret och ett sekundärt datacenter. Ett avståndskrav hjälper till att tillhandahålla tillgänglighet om en naturkatastrof inträffar på en bredare geografisk plats. Exempel är orkanerna som drabbade Karibien och Florida i september och oktober 2017. Din organisation kan ha minst ett minimikrav på avstånd. För de flesta Azure-kunder kräver en minsta avståndsdefinition att du utformar för tillgänglighet i Azure-regioner. Eftersom avståndet mellan två Azure-regioner är för stort för att använda HANA-synkront replikeringsläge kan RTO- och RPO-kraven tvinga dig att distribuera tillgänglighetskonfigurationer i en region och sedan komplettera med ytterligare distributioner i en andra region.
En annan aspekt att tänka på i det här scenariot är redundans och klientomdirigering. Antagandet är att en redundansväxling mellan SAP HANA-instanser i två olika Azure-regioner alltid är en manuell redundansväxling. Eftersom replikeringsläget för SAP HANA-systemreplikering är inställt på asynkron finns det en potential att data som har checkats in i den primära HANA-instansen ännu inte har tagit sig till den sekundära HANA-instansen. Därför är automatisk redundans inte ett alternativ för konfigurationer där replikeringen är asynkron. Även med manuellt kontrollerad redundans, som i en redundansövning, måste du vidta åtgärder för att säkerställa att alla incheckade data på den primära sidan tog sig till den sekundära instansen innan du manuellt flyttar över till den andra Azure-regionen.
Azure Virtual Network använder ett annat IP-adressintervall. IP-adresserna distribueras i den andra Azure-regionen. Så du måste antingen ändra SAP HANA-klientkonfigurationen, eller helst måste du skapa steg för att ändra namnmatchningen. På så sätt omdirigeras klienterna till den nya sekundära platsens server-IP-adress. Mer information finns i SAP-artikeln Klientanslutningsåterställning efter övertagande.
Enkel tillgänglighet mellan två Azure-regioner
Du kan välja att inte införa någon tillgänglighetskonfiguration i en enda region, men ändå ha efterfrågan på att få arbetsbelastningen hanterad om en katastrof inträffar. Typiska fall för sådana scenarier är icke-produktionssystem. Även om det är hållbart att ha systemet nere en halv dag eller till och med en dag, kan du inte tillåta att systemet är otillgängligt i 48 timmar eller mer. Om du vill göra installationen mindre kostsam kör du ett annat system som är ännu mindre viktigt på den virtuella datorn. Det andra systemet fungerar som mål. Du kan också ändra storleken på den virtuella datorn i den sekundära regionen så att den blir mindre och välja att inte förinläsa data. Eftersom redundansväxlingen är manuell och innebär många fler steg för att redundansväxla hela programstacken, är den ytterligare tiden det tar att stänga av den virtuella datorn, ändra storlek på den och sedan starta om den virtuella datorn.
Om du använder scenariot att dela DR-målet med ett QA-system på en virtuell dator måste du ta hänsyn till följande:
- Det finns två åtgärdslägen med delta_datashipping och logreplay, som är tillgängliga för ett sådant scenario
- Båda åtgärdslägena har olika minneskrav utan förinläsning av data
- Delta_datashipping kan kräva drastiskt mindre minne utan förinläsningsalternativet än vad logreplay kan kräva. Se kapitel 4.3 i SAP-dokumentet How To Perform System Replication for SAP HANA (Utför systemreplikering för SAP HANA)
- Minneskravet för logreplay-driftläge utan förinläsning är inte deterministiskt och beror på vilka kolumnlagringsstrukturer som läses in. I extrema fall kan du behöva 50 % av minnet för den primära instansen. Minnet för logreplay-åtgärdsläget är oberoende av om du har valt att ha data förinlästa eller inte.
Kommentar
I den här konfigurationen kan du inte ange ett RPO=0 eftersom hana-systemets replikeringsläge är asynkront. Om du behöver ange ett RPO=0 är den här konfigurationen inte den konfiguration som du väljer.
En liten ändring som du kan göra i konfigurationen kan vara att konfigurera data som förinläsning. Men med tanke på redundansens manuella karaktär och det faktum att programskikten också behöver flyttas till den andra regionen är det kanske inte meningsfullt att förinstallera data.
Kombinera tillgänglighet inom en region och mellan regioner
En kombination av tillgänglighet inom och mellan regioner kan bero på följande faktorer:
- Ett krav för RPO=0 i en Azure-region.
- Organisationen är inte villig eller kan ha globala åtgärder som påverkas av en större naturkatastrof som påverkar en större region. Detta var fallet för vissa orkaner som drabbat Karibien under de senaste åren.
- Regler som kräver avstånd mellan primära och sekundära platser som tydligt ligger utanför vad Azure-tillgänglighetszoner kan tillhandahålla.
I dessa fall kan du konfigurera vad SAP anropar en sap hana-konfiguration för flernivåsystemreplikering med hjälp av HANA-systemreplikering. Arkitekturen skulle se ut så här:
SAP introducerade systemreplikering med flera mål med HANA 2.0 SPS3. Systemreplikering med flera mål ger vissa fördelar i uppdateringsscenarier. Dr-platsen (region 2) påverkas till exempel inte när den sekundära HA-platsen är nere för underhåll eller uppdateringar. Du kan läsa mer om REPLIkering av HANA-system med flera mål på SAP-hjälpportalen. Möjlig arkitektur med replikering med flera mål skulle se ut så här:
Om organisationen har krav på hög tillgänglighetsberedskap i den andra (DR) Azure-regionen ser arkitekturen ut så här:
Med logreplay som åtgärdsläge tillhandahåller den här konfigurationen ett RPO=0, med låg RTO, inom den primära regionen. Konfigurationen ger också ett anständigt RPO om en flytt till den andra regionen är involverad. RTO-tiderna i den andra regionen är beroende av om data är förinlästa. Många kunder använder den virtuella datorn i den sekundära regionen för att köra ett testsystem. I så fall kan data inte förinläsas.
Viktigt!
Driftlägena mellan de olika nivåerna måste vara homogena. Du kan inte använda logreplay som åtgärdsläge mellan nivå 1 och nivå 2 och delta_datashipping för att tillhandahålla nivå 3. Du kan bara välja det ena eller det andra åtgärdsläget som måste vara konsekvent för alla nivåer. Eftersom delta_datashipping inte är lämplig för att ge dig ett RPO=0 förblir det enda rimliga driftläget för en sådan flernivåkonfiguration logreplay. Mer information om åtgärdslägen och vissa begränsningar finns i SAP-artikeln Driftlägen för SAP HANA-systemreplikering.
Nästa steg
Stegvisa anvisningar om hur du konfigurerar dessa konfigurationer i Azure finns i: