SAP HANA-tillgänglighet inom en Azure-region

Den här artikeln beskriver flera tillgänglighetsscenarier för SAP HANA i en Azure-region. Azure har många regioner, spridda över hela världen. Listan över Azure-regioner finns i Azure-regioner. För distribution av SAP HANA på virtuella datorer i en Azure-region erbjuder Microsoft distribution av en enda virtuell dator med en HANA-instans. För ökad tillgänglighet kan du distribuera två virtuella datorer med två HANA-instanser med antingen en flexibel skalningsuppsättning med FD=1, tillgänglighetszoner eller en tillgänglighetsuppsättning som använder HANA-systemreplikering för tillgänglighet.

Azure-regioner som tillhandahåller Tillgänglighetszoner består av flera datacenter, var och en med sin egen energikälla, kylning och nätverksinfrastruktur. Syftet med att erbjuda olika zoner i en enda Azure-region är att aktivera distribution av program över två eller tre tillgängliga Tillgänglighetszoner. Genom att distribuera programdistributionen mellan zoner skulle eventuella problem med ström eller nätverk som påverkar en specifik Infrastruktur för Azure-tillgänglighetszoner inte helt störa programmets funktioner i Azure-regionen. Även om det kan finnas en viss minskad kapacitet, till exempel potentiell förlust av virtuella datorer i en zon, skulle de virtuella datorerna i de återstående zonerna fortsätta att fungera utan avbrott. Om du vill konfigurera två HANA-instanser i separata virtuella datorer som sträcker sig över olika zoner har du möjlighet att distribuera virtuella datorer med antingen den flexibla skalningsuppsättningen med distributionsalternativet FD=1 eller tillgänglighetszoner .

För ökad tillgänglighet inom en region rekommenderar vi att du distribuerar två virtuella datorer med två HANA-instanser med hjälp av en tillgänglighetsuppsättning. En Azure-tillgänglighetsuppsättning är en logisk grupperingsfunktion som säkerställer att de virtuella datorresurser som konfigurerats i tillgänglighetsuppsättningen är felisolerade från varandra när de distribueras i ett Azure-datacenter. Azure ser till att de virtuella datorer du placerar i en tillgänglighetsuppsättning körs över flera fysiska servrar, datarack, lagringsenheter och nätverksväxlar. I viss Azure-dokumentation kallas den här konfigurationen för placeringar i olika uppdaterings- och feldomäner. Dessa placeringar finns vanligtvis i ett Azure-datacenter. Förutsatt att problem med strömkälla och nätverk skulle påverka det datacenter som du distribuerar påverkas all kapacitet i en Azure-region.

Placeringen av datacenter som representerar Azure Tillgänglighetszoner är en kompromiss mellan att leverera acceptabel nätverksfördröjning mellan tjänster som distribueras i olika zoner och ett avstånd mellan datacenter. Naturkatastrofer skulle helst inte påverka energi, nätförsörjning och infrastruktur för alla Tillgänglighetszoner i den här regionen. Men som monumentala naturkatastrofer har visat kanske Tillgänglighetszoner inte alltid ger den tillgänglighet som du vill ha inom en region. Tänk på orkanen Maria som drabbade ön Puerto Rico den 20 september 2017. Orkanen orsakade i princip ett nästan 100 procent strömavbrott på den 90 mil breda ön.

Scenario med en virtuell dator

I ett scenario med en virtuell dator skapar du en virtuell Azure-dator för SAP HANA-instansen. Du använder Azure Premium Storage som värd för operativsystemdisken och alla dina datadiskar. Azures serviceavtal för drifttid på 99,9 procent och serviceavtalen för andra Azure-komponenter räcker för att du ska kunna uppfylla dina tillgänglighets serviceavtal för dina kunder. I det här scenariot behöver du inte använda en Azure-tillgänglighetsuppsättning för virtuella datorer som kör DBMS-lagret. I det här scenariot förlitar du dig på två olika funktioner:

• Automatisk omstart av virtuella Azure-datorer (kallas även azure-tjänståterställning)
• Automatisk omstart av SAP HANA

Automatisk omstart av virtuella Azure-datorer eller tjänståterställning är en funktion i Azure som fungerar på två nivåer:

• Azure-servervärden kontrollerar hälsotillståndet för en virtuell dator som finns på servervärden.
• Azure Fabric-kontrollanten övervakar servervärdens hälsa och tillgänglighet.

En hälsokontrollfunktion övervakar hälsotillståndet för varje virtuell dator som finns på en Azure-servervärd. Om en virtuell dator inte är felfri kan en omstart av den virtuella datorn initieras av Azure-värdagenten som kontrollerar hälsotillståndet för den virtuella datorn. Infrastrukturkontrollanten kontrollerar värdens hälsa genom att kontrollera många olika parametrar som kan tyda på problem med värdmaskinvaran. Den kontrollerar också tillgängligheten för värden via nätverket. En indikation på problem med värden kan leda till följande händelser:

• Om värden signalerar ett dåligt hälsotillstånd utlöses en omstart av värden och en omstart av de virtuella datorer som kördes på värden.
• Om värden inte är i felfritt tillstånd efter en lyckad omstart initieras en omdistribution av de virtuella datorer som ursprungligen fanns på noden som nu inte är felfri på en felfri värdserver. I det här fallet markeras den ursprungliga värden som inte felfri. Den kommer inte att användas för ytterligare distributioner förrän den har rensats eller ersatts.
• Om den felaktiga värden har problem under omstartsprocessen utlöses en omedelbar omstart av de virtuella datorerna på en felfri värd.

Med den värd- och VM-övervakning som tillhandahålls av Azure startas virtuella Azure-datorer som upplever värdproblem automatiskt om på en felfri Azure-värd.

Viktigt!

Azure-tjänståterställning startar inte om virtuella Linux-datorer där gästoperativsystemet är i kernel-paniktillstånd. Standardinställningarna för de vanliga Linux-versionerna startar inte automatiskt om virtuella datorer eller servrar där Linux-kerneln är i paniktillstånd. I stället förutser standardinställningen att operativsystemet ska vara i kernel-paniktillstånd för att kunna ansluta en kernelfelsökare för att analysera. Azure respekterar det beteendet genom att inte automatiskt starta om en virtuell dator med gästoperativsystemet i ett sådant tillstånd. Antagandet är att sådana förekomster är extremt sällsynta. Du kan skriva över standardbeteendet för att aktivera en omstart av den virtuella datorn. Om du vill ändra standardbeteendet aktiverar du parametern "kernel.panic" i /etc/sysctl.conf. Tiden som du anger för den här parametern är i sekunder. Vanliga rekommenderade värden är att vänta i 20–30 sekunder innan omstarten utlöses via den här parametern. Mer information finns i sysctl.conf.

Den andra funktionen som du förlitar dig på i det här scenariot är det faktum att HANA-tjänsten som körs i en omstartad virtuell dator startar automatiskt efter omstarten av den virtuella datorn. Du kan konfigurera automatisk omstart av HANA-tjänsten via övervakningstjänsterna för de olika HANA-tjänsterna.

Du kan förbättra det här scenariot med en virtuell dator genom att lägga till en kall redundansnod i en SAP HANA-konfiguration. I SAP HANA-dokumentationen kallas den här konfigurationen värd för autofailover. Den här konfigurationen kan vara meningsfull i en lokal distributionssituation där servermaskinvaran är begränsad och du tillägnar en nod med en enskild server som värdnod för automatisk överlagring för en uppsättning produktionsvärdar. Men i Azure, där den underliggande infrastrukturen i Azure tillhandahåller en felfri målserver för en lyckad omstart av den virtuella datorn, är det inte meningsfullt att distribuera automatisk distribution av SAP HANA-värd. På grund av Azure-tjänståterställning finns det ingen referensarkitektur som förutser en väntelägesnod för HANA-värd autofailover.

Specialfall för SAP HANA-utskalningskonfigurationer i Azure

Arkitekturer med hög tillgänglighet baserat på väntelägesnod eller HANA-systemreplikering finns i följande dokument. I de fall där väntelägesnoder eller HANA-systemreplikering med hög tillgänglighet inte används i SAP HANA-utskalningskonfigurationer kan du vara beroende av tjänståterställningsfunktionerna för virtuella Azure-datorer och den automatiska omstarten av SAP HANA-instansen när den virtuella datorn är i drift igen.

• RedHat Enterprise Linux
  • Hög tillgänglighet för SAP HANA-utskalningssystem med HSR på RHEL.
  • Distribuera ett SAP HANA-utskalningssystem med väntelägesnod på virtuella Azure-datorer med hjälp av Azure NetApp Files på RHEL.
• SUSE Linux Enterprise Server
  • Hög tillgänglighet för SAP HANA-utskalningssystem med HSR på SLES.
  • Distribuera ett SAP HANA-utskalningssystem med väntelägesnod på virtuella Azure-datorer med hjälp av Azure NetApp Files på SLES.

Tillgänglighetsscenarier för två olika virtuella datorer

För att säkerställa tillgängligheten för HANA-systemet inom en viss region har du möjlighet att konfigurera två virtuella datorer i tillgänglighetszonerna i regionen eller i regionen. För att uppnå det här målet kan du konfigurera de virtuella datorerna med hjälp av flexibel skalningsuppsättning, tillgänglighetszoner eller distributionsalternativ för tillgänglighetsuppsättningar. Baskonfigurationen i Azure skulle se ut så här:

För att illustrera de olika SAP HANA-tillgänglighetsscenarierna utelämnas några av lagren i diagrammet. Diagrammet visar endast lager som visar virtuella datorer, värdar, tillgänglighetsuppsättningar och Azure-regioner. Azure Virtual Network-instanser, resursgrupper och prenumerationer spelar ingen roll i de scenarier som beskrivs i det här avsnittet.

Replikera säkerhetskopior till en andra virtuell dator

En av de mest rudimentära installationerna är att använda säkerhetskopior. I synnerhet kan du ha säkerhetskopieringar av transaktionsloggar som levereras från en virtuell dator till en annan virtuell Azure-dator. Du kan välja Azure Storage-typ. I den här konfigurationen ansvarar du för att skripta kopian av schemalagda säkerhetskopior som utförs på den första virtuella datorn till den andra virtuella datorn. Om du behöver använda de andra virtuella datorinstanserna måste du återställa de fullständiga, inkrementella/differentiella säkerhetskopiorna och transaktionsloggen till den punkt du behöver.

Arkitekturen ser ut så här:

Den här konfigurationen lämpar sig inte för att uppnå stora mål för återställningspunkt (RPO) och mål för återställningstid (RTO). RTO-tider skulle särskilt drabbas på grund av behovet av att helt återställa den fullständiga databasen med hjälp av de kopierade säkerhetskopiorna. Den här konfigurationen är dock användbar för att återställa från oavsiktlig databorttagning på huvudinstanserna. Med den här konfigurationen kan du när som helst återställa till en viss tidpunkt, extrahera data och importera borttagna data till huvudinstansen. Därför kan det vara klokt att använda en metod för säkerhetskopieringskopiering i kombination med andra funktioner för hög tillgänglighet.

Medan säkerhetskopior kopieras kanske du kan använda en mindre virtuell dator än den virtuella huvuddatorn som SAP HANA-instansen körs på. Tänk på att du kan koppla ett mindre antal virtuella hårddiskar till mindre virtuella datorer. Information om gränserna för enskilda typer av virtuella datorer finns i Storlekar för virtuella Linux-datorer i Azure.

SAP HANA-systemreplikering utan automatisk redundans

De scenarier som beskrivs i det här avsnittet använder SAP HANA-systemreplikering. Sap-dokumentationen finns i Systemreplikering. Scenarier utan automatisk redundans är inte vanliga för konfigurationer i en Azure-region. En konfiguration utan automatisk redundans, men om du undviker en Pacemaker-konfiguration, måste du övervaka och redundans manuellt. Eftersom detta också tar och arbetar förlitar sig de flesta kunder på Azure-tjänståterställning i stället. Det finns vissa gränsfall där den här konfigurationen kan vara till hjälp när det gäller felscenarier. Eller i vissa fall kanske en kund vill öka effektiviteten.

SAP HANA-systemreplikering utan automatisk redundans och utan förinläsning av data

I det här scenariot använder du SAP HANA-systemreplikering för att flytta data på ett synkront sätt för att uppnå ett RPO på 0. Å andra sidan har du en tillräckligt lång RTO som du inte behöver redundansväxling eller data förinläsning i HANA-instanscachen. I det här fallet är det möjligt att uppnå ytterligare ekonomi i konfigurationen genom att vidta följande åtgärder:

• Kör en annan SAP HANA-instans på den andra virtuella datorn. SAP HANA-instansen på den andra virtuella datorn tar det mesta av minnet på den virtuella datorn. Om du redundansväxlar till den andra virtuella datorn måste du stänga av den SAP HANA-instans som körs som har data helt inlästa på den andra virtuella datorn, så att replikerade data kan läsas in i cacheminnet för den riktade HANA-instansen på den andra virtuella datorn.
• Använd en mindre VM-storlek på den andra virtuella datorn. Om en redundansväxling inträffar har du ytterligare ett steg före den manuella redundansväxlingen. I det här steget ändrar du storlek på den virtuella datorn till storleken på den virtuella källdatorn.

Scenariot ser ut så här:

Kommentar

Även om du inte använder förinläsning av data i HANA-systemets replikeringsmål behöver du minst 64 GB minne. Du behöver också tillräckligt med minne utöver 64 GB för att behålla radlagringsdata i målinstansens minne.

SAP HANA-systemreplikering utan automatisk redundans och med förinläsning av data

I det här scenariot förinstalleras data som replikeras till HANA-instansen på den andra virtuella datorn. Detta eliminerar de två fördelarna med att inte förinstallera data. I det här fallet kan du inte köra ett annat SAP HANA-system på den andra virtuella datorn. Du kan inte heller använda en mindre VM-storlek. Därför implementerar kunderna sällan det här scenariot.

SAP HANA-systemreplikering med automatisk redundans

I standardkonfigurationen och den vanligaste tillgängligheten i en Azure-region har två virtuella Azure-datorer som kör Linux med HA-paket ett definierat redundanskluster. HA Linux-klustret baseras på ramverket Pacemaker med SLES eller RHEL med en fencing device SLES eller RHEL som exempel.

Från ett SAP HANA-perspektiv synkroniseras replikeringsläget som används och en automatisk redundansväxling konfigureras. På den andra virtuella datorn fungerar SAP HANA-instansen som en het väntelägesnod. Väntelägesnoden tar emot en synkron ström med ändringsposter från den primära SAP HANA-instansen. När transaktioner utförs av programmet på den primära HANA-noden väntar den primära HANA-noden på att bekräfta incheckningen till programmet tills den sekundära SAP HANA-noden bekräftar att den har tagit emot incheckningsposten. SAP HANA erbjuder två synkrona replikeringslägen. Mer information och en beskrivning av skillnaderna mellan dessa två synkrona replikeringslägen finns i SAP-artikeln Replikeringslägen för SAP HANA-systemreplikering.

Den övergripande konfigurationen ser ut så här:

Du kan välja den här lösningen eftersom den gör att du kan uppnå ett RPO=0 och en låg RTO. Konfigurera SAP HANA-klientanslutningen så att SAP HANA-klienterna använder den virtuella IP-adressen för att ansluta till HANA-systemreplikeringskonfigurationen. En sådan konfiguration eliminerar behovet av att konfigurera om programmet om en redundansväxling till den sekundära noden inträffar. I det här scenariot måste SKU:er för virtuella Azure-datorer för de primära och sekundära virtuella datorerna vara desamma.

Nästa steg

Stegvisa anvisningar om hur du konfigurerar dessa konfigurationer i Azure finns i:

• Konfigurera SAP HANA-systemreplikering på virtuella Azure-datorer
• Hög tillgänglighet för SAP HANA med hjälp av systemreplikering

Mer information om SAP HANA-tillgänglighet i Azure-regioner finns i:

• SAP HANA-tillgänglighet i Azure-regioner