Konfigurationer och åtgärder för SAP HANA i Azure-infrastrukturer

Det här dokumentet innehåller vägledning för att konfigurera Azure-infrastruktur och använda SAP HANA-system som distribueras på virtuella Azure-datorer (VM). Dokumentet innehåller även konfigurationsinformation för SAP HANA-utskalning för den virtuella M128-datorns SKU. Det här dokumentet är inte avsett att ersätta SAP-standarddokumentationen, som innehåller följande innehåll:

• SAP-administrationsguide
• SAP-installationsguider
• SAP-anteckningar

Förutsättningar

Om du vill använda den här guiden behöver du grundläggande kunskaper om följande Azure-komponenter:

• Azure Virtual Machines
• Azure-nätverk och virtuella nätverk
• Azure Storage

Mer information om SAP NetWeaver och andra SAP-komponenter i Azure finns i avsnittet SAP on Azure i Azure-dokumentationen.

Grundläggande konfigurationsöverväganden

I följande avsnitt beskrivs grundläggande konfigurationsöverväganden för distribution av SAP HANA-system på virtuella Azure-datorer.

Ansluta till virtuella Azure-datorer

Som beskrivs i planeringsguiden för virtuella Azure-datorer finns det två grundläggande metoder för att ansluta till virtuella Azure-datorer:

• Anslut via internet och offentliga slutpunkter på en Jump VM eller på den virtuella dator som kör SAP HANA.
• Anslut via ett VPN eller Azure ExpressRoute.

Plats-till-plats-anslutning via VPN eller ExpressRoute krävs för produktionsscenarier. Den här typen av anslutning behövs också för scenarier som inte är produktionsscenarier där SAP-programvara används. Följande bild visar ett exempel på anslutning mellan platser:

Välj typer av virtuella Azure-datorer

SAP listar vilka typer av virtuella Azure-datorer som du kan använda för produktionsscenarier. För scenarier som inte är produktionsbaserade är en bredare mängd olika typer av interna virtuella Azure-datorer tillgängliga.

Distribuera de virtuella datorerna i Azure med hjälp av:

• Azure-portalen.
• Azure PowerShell-cmdlets.
• Azure CLI.

Lagringskonfiguration för SAP HANA

För lagringskonfigurationer och lagringstyper som ska användas med SAP HANA i Azure läser du dokumentet sap hana azure virtual machine storage configurations

Konfigurera virtuella Azure-nätverk

När du har plats-till-plats-anslutning till Azure via VPN eller ExpressRoute måste du ha minst ett virtuellt Azure-nätverk som är anslutet via en virtuell gateway till VPN- eller ExpressRoute-kretsen. I enkla distributioner kan den virtuella gatewayen distribueras i ett undernät i det virtuella Azure-nätverket (VNet) som också är värd för SAP HANA-instanserna. Om du vill installera SAP HANA skapar du ytterligare två undernät i det virtuella Azure-nätverket. Ett undernät är värd för de virtuella datorerna för att köra SAP HANA-instanserna. Det andra undernätet hanterar Jumpbox eller hanteringsdatorer som är värdar för SAP HANA Studio, annan hanteringsprogramvara eller applikationsprogramvara.

Om du har distribuerat jumpbox- eller hanteringsdatorer i ett separat undernät kan du definiera flera virtuella nätverkskort (vNIC) för den virtuella HANA-datorn, där varje virtuellt nätverkskort har tilldelats till olika undernät. Med möjligheten att ha flera virtuella nätverkskort kan du konfigurera nätverkstrafikavgränsning om det behövs. Till exempel kan klienttrafik dirigeras via det primära virtuella nätverkskortet och administratörstrafiken dirigeras via ett andra virtuellt nätverkskort.
Du tilldelar också statiska privata IP-adresser som distribueras för båda virtuella nätverkskorten.

För distributioner som är varaktiga måste du dock skapa en nätverksarkitektur för virtuella datacenter i Azure. Den här arkitekturen rekommenderar att du separerar den Virtuella Azure-gatewayen som ansluter till en lokal plats i ett separat virtuellt Azure-nätverk. Det här separata virtuella nätverket ska vara värd för all trafik som lämnar antingen till lokalt eller till Internet. Med den här metoden kan du distribuera programvara för granskning och loggning av trafik som kommer in i det virtuella datacentret i Azure i det här separata virtuella hubbnätverket. Så du har ett virtuellt nätverk som är värd för alla program och konfigurationer som är relaterade till in- och utgående trafik till din Azure-distribution.

Artiklarna Azure Virtual Datacenter: A Network Perspective och Azure Virtual Datacenter och Enterprise Control Plane ger mer information om den virtuella datacentermetoden och relaterad Azure VNet-design.

En översikt över de olika metoderna för att tilldela IP-adresser finns i IP-adresstyper och allokeringsmetoder i Azure.

För virtuella datorer som kör SAP HANA bör du arbeta med statiska IP-adresser tilldelade. Anledningen är att vissa konfigurationsattribut för HANA refererar till IP-adresser.

Azure Network Security Groups (NSG:er) används för att styra trafik till SAP HANA-instansen eller jumpboxen. NSG:er och slutligen programsäkerhetsgrupper är associerade med SAP HANA-undernätet och undernätet Hantering.

Om du vill distribuera SAP HANA i Azure utan plats-till-plats-anslutning vill du fortfarande skydda SAP HANA-instansen från det offentliga Internet och dölja den bakom en framåtriktad proxy. I det här grundläggande scenariot förlitar sig distributionen på Inbyggda DNS-tjänster i Azure för att matcha värdnamn. I en mer komplex distribution där offentliga IP-adresser används är inbyggda DNS-tjänster i Azure särskilt viktiga. Använd Azure NSG:er och Azure NVA:er för att styra, övervaka routningen från Internet till din Azure VNet-arkitektur i Azure. Följande bild visar ett översiktligt schema för att distribuera SAP HANA utan en plats-till-plats-anslutning i en VNet-arkitektur i nav-och-ekermodell.

En annan beskrivning av hur du använder Azure NVA:er för att kontrollera och övervaka åtkomsten från Internet utan att använda hubb-och-ekers VNet-arkitektur finns i artikeln Distribuera hög tillgänglighet för nätverksvirtuella enheter.

Alternativ för klockkälla på virtuella Azure-datorer

SAP HANA kräver tillförlitlig och korrekt tidsinformation för att prestera optimalt. Traditionellt använde virtuella Azure-datorer som körs på Azure hypervisor endast Hyper-V TSC-sidan som standardklockakälla. Tekniska framsteg inom maskinvara, värdoperativsystem och Linux-gästoperativsystemkärnor gjorde det möjligt att tillhandahålla "Invariant TSC" som ett klockkällalternativ på vissa SKU:er för virtuella Azure-datorer.

Hyper-V TSC-sidan (hyperv_clocksource_tsc_page) stöds på alla virtuella Azure-datorer som en klockkälla. Om den underliggande maskinvaran, hypervisorn och gästoperativsystemets Linux-kärna stöder Invariant TSC, kommer tsc att erbjudas som en tillgänglig och stödd klockkälla i gästoperativsystemet på virtuella Azure-datorer.

Konfigurera Azure-infrastruktur för SAP HANA-utskalning

Om du vill ta reda på vilka typer av virtuella Azure-datorer som är certifierade för antingen OLAP-utskalning eller S/4HANA-utskalning kan du läsa katalogen för SAP HANA-maskinvara. En bockmarkering i kolumnen "Klustring" anger utskalningsstöd. Programtyp anger om OLAP-utskalning eller S/4HANA-utskalning stöds. Mer information om noder som certifierats för scale-out finns i posten för en specifik VM SKU som anges i SAP HANA-maskinvarukatalogen.

De lägsta versionerna av operativsystemet för implementering av utskalningskonfigurationer på virtuella Azure-datorer, kontrollera detaljerna om posterna i den specifika VM SKU som listas i SAP HANA-maskinvarukatalogen. En nod fungerar som huvudnod för en OLAP-utskalningskonfiguration med n-nod. De andra noderna upp till certifieringsgränsen fungerar som arbetsnoder. Fler väntelägesnoder räknas inte in i antalet certifierade noder

För /hana/shared rekommenderar vi användning av Azure NetApp Files eller Azure Files.

En typisk grundläggande design för en enskild nod i en utskalningskonfiguration, med /hana/shared distribuerad i Azure NetApp Files, ser ut så här:

Den grundläggande konfigurationen av en VM-nod för SAP HANA-utskalning ser ut så här:

• För /hana/shared använder du den interna NFS-tjänsten som tillhandahålls via Azure NetApp Files eller Azure Files.
• Alla andra diskvolymer delas inte mellan de olika noderna och baseras inte på NFS. Installationskonfigurationer och steg för utskalning av HANA-installationer med icke-delade /hana/data och /hana/log tillhandahålls längre fram i det här dokumentet. För HANA-certifierad lagring som kan användas kan du läsa artikeln sap hana azure virtual machine storage configurations.

När du ändrar storlek på volymer eller diskar måste du kontrollera dokumentet SAP HANA TDI-lagringskrav för den storlek som krävs beroende på antalet arbetsnoder. Dokumentet släpper en formel som du måste tillämpa för att få den kapacitet som krävs för volymen

De andra designkriterierna som visas i grafiken för konfigurationen av en enskild nod för en skalbar virtuell SAP HANA-dator är det virtuella nätverket, eller bättre konfiguration av undernätet. SAP rekommenderar starkt en separation av klient-/programriktad trafik från kommunikationen mellan HANA-noderna. Som du ser i grafiken uppnås det här målet genom att ha två olika virtuella nätverkskort kopplade till den virtuella datorn. Båda virtuella nätverkskort (vNICs) finns i var sitt undernät och har var sin unik IP-adress. Sedan styr du trafikflödet med routningsregler med hjälp av NSG:er eller användardefinierade vägar.

Särskilt i Azure finns det inga metoder för att framtvinga tjänstkvalitet och kvoter på specifika virtuella nätverkskort. Därför öppnar inte separationen av klient-/programriktad och intranodkommunikation några möjligheter att prioritera en trafikström framför den andra. I stället förblir separationen ett säkerhetsmått för att avskärma kommunikationen mellan noder i utskalningskonfigurationerna.

Från nätverkssynpunkt skulle den minsta nödvändiga nätverksarkitekturen se ut så här:

Installera SAP HANA scale-out i Azure

När du installerar en skalbar SAP-konfiguration måste du utföra grova steg i:

• Distribuera ny eller anpassa en befintlig Azure VNet-infrastruktur
• Distribuera de nya virtuella datorerna med Azure Managed Premium Storage, Ultra-diskvolymer och/eller NFS-volymer baserat på ANF
• • Anpassa nätverksroutning för att se till att till exempel kommunikation mellan noder mellan virtuella datorer inte dirigeras via en NVA.
• Installera SAP HANA-huvudnoden.
• Anpassa konfigurationsparametrarna för SAP HANA-huvudnoden
• Fortsätt med installationen av SAP HANA-arbetsnoderna

Installation av SAP HANA i utskalningskonfiguration

När infrastrukturen för den virtuella Azure-datorn distribueras och alla andra förberedelser är klara måste du installera SAP HANA-utskalningskonfigurationerna i följande steg:

• Installera SAP HANA-huvudnoden enligt SAP:s dokumentation
• När du använder Azure Premium Storage eller Ultra-disklagring med icke-delade diskar av /hana/data och /hana/loglägger du till parametern basepath_shared = no i global.ini filen. Med den här parametern kan SAP HANA köras i utskalning utan delade /hana/data volymer och /hana/log volymer mellan noderna. Information dokumenteras i SAP Note #2080991. Om du använder NFS-volymer baserat på ANF för /hana/data och /hana/log behöver du inte göra den här ändringen
• Starta om SAP HANA-instansen efter den slutliga ändringen i parametern global.ini
• Lägg till fler arbetsnoder. Mer information finns i Lägga till värdar med kommandoradsgränssnittet. Ange det interna nätverket för SAP HANA-kommunikation mellan noder under installationen eller därefter med hjälp av till exempel den lokala hdblcmen. Mer detaljerad dokumentation finns i SAP Note #2183363.

Information om hur du konfigurerar ett SAP HANA-skalningssystem med en väntelägesnod finns i SUSE Linux-distributionsinstruktionerna eller Red Hat-distributionsinstruktionerna.

SAP HANA Dynamic Tiering 2.0 för virtuella Azure-datorer

Förutom SAP HANA-certifieringar på virtuella Datorer i Azure M-serien stöds även SAP HANA Dynamic Tiering 2.0 på Microsoft Azure. Mer information finns i Länkar till DT 2.0-dokumentation. Det finns ingen skillnad när det gäller att installera eller använda produkten. Du kan till exempel installera SAP HANA Cockpit på en virtuell Azure-dator. Det finns dock vissa obligatoriska krav, som beskrivs i följande avsnitt, för officiell support i Azure. I hela artikeln kommer förkortningen "DT 2.0" att användas istället för det fullständiga namnet Dynamic Tiering 2.0.

SAP HANA Dynamic Tiering 2.0 stöds inte av SAP BW eller S4HANA. Huvudsakliga användningsfall just nu är interna HANA-program.

Översikt

Bilden nedan ger en översikt över DT 2.0-support på Microsoft Azure. Det finns en uppsättning obligatoriska krav som måste följas för att uppfylla den officiella certifieringen:

• DT 2.0 måste installeras på en dedikerad virtuell Azure-dator. Den kanske inte körs på samma virtuella dator där SAP HANA körs
• Virtuella SAP HANA- och DT 2.0-datorer måste distribueras i samma virtuella Azure-nätverk
• De virtuella SAP HANA- och DT 2.0-datorerna måste distribueras med Azure-accelererat nätverk aktiverat
• Lagringstyp för de virtuella DT 2.0-datorerna måste vara Azure Premium Storage
• Flera Azure-diskar måste vara anslutna till den virtuella DT 2.0-datorn
• Det krävs att skapa en programvaru-RAID/randig volym (antingen via lvm eller mdadm) med striping över Azure-diskarna

Mer information kommer att förklaras i följande avsnitt.

Dedikerad virtuell Azure-dator för SAP HANA DT 2.0

På Azure IaaS stöds DT 2.0 endast på en dedikerad virtuell dator. Det är inte tillåtet att köra DT 2.0 på samma virtuella Azure-dator där HANA-instansen körs. Inledningsvis kan två typer av virtuella datorer användas för att köra SAP HANA DT 2.0:

• M64-32ms
• E32sv3

Mer information om beskrivningen av VM-typ finns i Storlekar på virtuella Azure-datorer – Minne

Med tanke på den grundläggande idén med DT 2.0, som handlar om att avlasta "varma" data för att spara kostnader, är det vettigt att använda motsvarande VM-storlekar. Det finns dock ingen strikt regel för möjliga kombinationer. Det beror på den specifika kundarbetsbelastningen.

Rekommenderade konfigurationer är:

Alla kombinationer av SAP HANA-certifierade virtuella datorer i M-serien med DT 2.0-datorer som stöds (M64-32ms och E32sv3) är möjliga.

Azure-nätverk och SAP HANA DT 2.0

För att installera DT 2.0 på en dedikerad virtuell dator krävs nätverksdataflöde mellan den virtuella DT 2.0-datorn och den virtuella SAP HANA-datorn på minst 10 Gb. Därför är det obligatoriskt att placera alla virtuella datorer i samma virtuella Azure-nätverk och aktivera Azure-accelererat nätverk.

Se ytterligare information om Azure-accelererat nätverk Skapa en virtuell Azure-dator med accelererat nätverk med Azure CLI

VM Storage för SAP HANA DT 2.0

Enligt bästa praxis för DT 2.0 bör diskens I/O-dataflöde vara minst 50 MB/s per fysisk kärna.

Enligt specifikationerna för de två typerna av virtuella Azure-datorer, som stöds för DT 2.0, ser den maximala disk-I/O-dataflödesgränsen för den virtuella datorn ut så här:

• E32sv3: 768 MB/s (ej åtskilt) vilket innebär ett förhållande på 48 MB/sek per fysisk kärna
• M64-32ms: 1 000 MB/s (ej cachelagrad), vilket är 62,5 MB/s per fysisk kärna

Du måste ansluta flera Azure-diskar till den virtuella DT 2.0-datorn och skapa en programräd (striping) på OS-nivå för att uppnå den maximala gränsen för diskdataflöde per virtuell dator. En enskild Azure-disk kan inte tillhandahålla den dataöverföringshastighet som krävs för att uppnå den maximala gränsen för VM i detta avseende. Azure Premium Storage är obligatoriskt för att köra DT 2.0.

• Information om tillgängliga Azure-disktyper finns på sidan Välj en disktyp för virtuella Azure IaaS-datorer – hanterade diskar
• Information om hur du skapar en programräd via mdadm finns på sidan Konfigurera programvaru-RAID på en virtuell Linux-dator
• Information om hur du konfigurerar LVM för att skapa en randig volym för maximalt dataflöde finns på sidan Konfigurera LVM på en virtuell dator som kör Linux

Beroende på storlekskrav finns det olika alternativ för att nå det maximala dataflödet för en virtuell dator. Här är möjliga diskkonfigurationer för datavolymer för varje typ av virtuell DT 2.0-dator för att uppnå den övre dataflödesgränsen för virtuella datorer. Den virtuella E32sv3-datorn bör betraktas som en startnivå för mindre arbetsbelastningar. Om det skulle visa sig att det inte är tillräckligt snabbt kan det vara nödvändigt att ändra storlek på den virtuella datorn till M64-32ms. Eftersom den virtuella M64-32ms-datorn har mycket minne kanske I/O-belastningen inte når gränsen, särskilt för läsintensiva arbetsbelastningar. Därför kan färre diskar i stripe-uppsättningen vara tillräckliga beroende på kundens specifika arbetsbelastning. Men för att vara på den säkra sidan valdes diskkonfigurationerna nedan för att garantera maximalt dataflöde:

Särskilt om arbetsbelastningen är läsintensiv kan det rekommenderas att aktivera Azures värd-cache som "skrivskyddad" för att förbättra I/O-prestanda för datavolymer i databasprogramvaran. För transaktionsloggen måste Azure-värddiskens cache vara "ingen".

När det gäller storleken på loggvolymen är en rekommenderad startpunkt en heuristik på 15 % av datastorleken. Du kan skapa loggvolymen genom att använda olika Typer av Azure-diskar beroende på kostnader och dataflödeskrav. För loggvolymen krävs ett högt I/O-dataflöde.

När du använder vm-typen M64-32ms är det obligatoriskt att aktivera skrivaccelerator. Azure Write Accelerator ger optimal svarstid för diskskrivning för transaktionsloggen (endast tillgänglig för M-serien). Det finns vissa objekt att tänka på, till exempel det maximala antalet diskar per vm-typ. Information om skrivaccelerator finns på Azure Write Accelerator-sidan

Här följer några exempel på hur du ändrar storlek på loggvolymen:

Precis som för SAP HANA-utskalning måste katalogen /hana/shared delas mellan den virtuella SAP HANA-datorn och den virtuella DT 2.0-datorn. Samma arkitektur som för SAP HANA-utskalning med dedikerade virtuella datorer, som fungerar som en NFS-server med hög tillgänglighet rekommenderas. För att tillhandahålla en delad säkerhetskopieringsvolym kan den identiska designen användas. Men det är upp till kunden om ha skulle vara nödvändigt eller om det räcker att bara använda en dedikerad virtuell dator med tillräckligt med lagringskapacitet för att fungera som en säkerhetskopieringsserver.

Länkar till DT 2.0-dokumentation

• Installations- och uppdateringsguide för SAP HANA Dynamic Tiering
• Självstudier och resurser för dynamisk nivåindelning i SAP HANA
• SAP HANA Dynamic Tiering PoC
• Förbättringar av dynamisk nivåindelning för SAP HANA 2.0 SPS 02

Åtgärder för att distribuera SAP HANA på virtuella Azure-datorer

I följande avsnitt beskrivs några av de åtgärder som rör distribution av SAP HANA-system på virtuella Azure-datorer.

Säkerhetskopierings- och återställningsåtgärder på virtuella Azure-datorer

Följande dokument beskriver hur du säkerhetskopierar och återställer din SAP HANA-distribution:

• Översikt över SAP HANA-säkerhetskopiering
• SAP HANA-säkerhetskopiering på filnivå
• SAP HANA-lagringsögonblickstest

Starta och starta om virtuella datorer som innehåller SAP HANA

En framträdande funktion i det offentliga Azure-molnet är att du bara debiteras för dina databehandlingsminuter. När du till exempel stänger av en virtuell dator som kör SAP HANA debiteras du endast för lagringskostnaderna under den tiden. En annan funktion är tillgänglig när du anger statiska IP-adresser för dina virtuella datorer i den första distributionen. När du startar om en virtuell dator som har SAP HANA startas den virtuella datorn om med sina tidigare IP-adresser.

Använda SAProuter för SAP-fjärrsupport

Om du har en plats-till-plats-anslutning mellan dina lokala platser och Azure, och du kör SAP-komponenter, kör du förmodligen redan SAProuter. I det här fallet slutför du följande objekt för fjärrsupport:

• Underhålla den privata och statiska IP-adressen för den virtuella dator som är värd för SAP HANA i SAProuter-konfigurationen.
• Konfigurera NSG för det undernät som är värd för den virtuella HANA-datorn för att tillåta trafik via TCP/IP-port 3299.

Om du ansluter till Azure via Internet och du inte har någon SAP-router för den virtuella datorn med SAP HANA måste du installera komponenten. Installera SAProuter på en separat virtuell dator i undernätet Hantering. Följande bild visar ett grovt schema för distribution av SAP HANA utan plats-till-plats-anslutning och med SAProuter:

Se till att installera SAProuter på en separat virtuell dator och inte i den virtuella Jumpbox-datorn. Den separata virtuella datorn måste ha en statisk IP-adress. Om du vill ansluta DIN SAProuter till DEN SAProuter som hanteras av SAP kontaktar du SAP för en IP-adress. (SAProuter som hanteras av SAP är motsvarigheten till den SAProuter-instans som du installerar på den virtuella datorn.) Använd IP-adressen från SAP för att konfigurera din SAProuter-instans. I konfigurationsinställningarna är den enda nödvändiga porten TCP-port 3299.

Mer information om hur du konfigurerar och underhåller fjärrsupportanslutningar via SAProuter finns i SAP-dokumentationen.

Hög tillgänglighet med SAP HANA på inbyggda virtuella Azure-datorer

Om du kör SUSE Linux Enterprise Server eller Red Hat kan du upprätta ett Pacemaker-kluster med fäktningsenheter. Du kan använda enheterna för att konfigurera en SAP HANA-konfiguration som använder synkron replikering med HANA-systemreplikering och automatisk redundans. Mer information finns i avsnittet "nästa steg".

Nästa steg

Bekanta dig med artiklarna enligt listan

• Lagringskonfigurationer för virtuella SAP HANA Azure-datorer
• Distribuera ett SAP HANA-utskalningssystem med väntelägesnod på virtuella Azure-datorer med hjälp av Azure NetApp Files på SUSE Linux Enterprise Server
• Distribuera ett SAP HANA-utskalningssystem med väntelägesnod på virtuella Azure-datorer med hjälp av Azure NetApp Files på Red Hat Enterprise Linux
• Distribuera ett SAP HANA-utskalningssystem med HSR och Pacemaker på virtuella Azure-datorer på SUSE Linux Enterprise Server
• Distribuera ett SAP HANA-utskalningssystem med HSR och PAcemaker på virtuella Azure-datorer i Red Hat Enterprise Linux
• Hög tillgänglighet för SAP HANA på virtuella Azure-datorer på SUSE Linux Enterprise Server
• Hög tillgänglighet för SAP HANA på virtuella Azure-datorer på Red Hat Enterprise Linux