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

  • Artikel
  • 18 minuter för att läsa

Det här dokumentet innehåller vägledning för att konfigurera Azure-infrastruktur SAP HANA operativsystem som distribueras på azure-interna virtuella datorer (VM). Dokumentet innehåller även konfigurationsinformation för att SAP HANA för M128s VM SKU. Det här dokumentet är inte avsett att ersätta SAP-standarddokumentationen, som innehåller följande innehåll:

Förutsättningar

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

Mer information om SAP NetWeaver och andra SAP-komponenter i Azure finns i SAP på Azure i Azure-dokumentationen.

Grundläggande konfigurationsöverväganden

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

Anslut till virtuella Azure-datorer

Enligt beskrivningen i planeringsguiden för virtuella Azure-datorerfinns det två grundläggande metoder för att ansluta till virtuella Azure-datorer:

  • Anslut via Internet och offentliga slutpunkter på en virtuell Jump-dator 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 icke-produktionsscenarier som matas in i produktionsscenarier där SAP-programvara används. Följande bild visar ett exempel på anslutning mellan webbplatser:

Anslutning mellan webbplatser

Välj typer av virtuella Azure-datorer

De typer av virtuella Azure-datorer som kan användas för produktionsscenarier finns i SAP-dokumentationen för IAAS. För icke-produktionsscenarier finns en bredare uppsättning inbyggda typer av virtuella Azure-datorer tillgängliga.

Anteckning

För icke-produktionsscenarier använder du de VM-typer som anges i SAP-anteckningen #1928533. För användning av virtuella Azure-datorer för produktionsscenarier kan du söka efter SAP HANA certifierade virtuella datorer i sap-listan Över certifierade IaaS-plattformar.

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

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

Du kan också distribuera en komplett installerad SAP HANA plattform på Azure VM-tjänsterna via SAP Cloud-plattformen. Installationsprocessen beskrivs i Distribuera SAP S/4HANA eller BW/4HANA på Azure eller med den automatisering som släpptes den GitHub.

Viktigt

För att kunna använda M208xx_v2 virtuella datorer måste du vara noga med att välja din Linux-avbildning. Mer information finns i Storlekar på minnesoptimerade virtuella datorer.

Storage konfiguration för SAP HANA

Information om lagringskonfigurationer och lagringstyper som ska användas med SAP HANA Azure finns i dokumentet om SAP HANA lagringskonfigurationer för virtuella Azure-datorer

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 även är värd för SAP HANA instanser. Om du SAP HANA måste du skapa ytterligare två undernät i det virtuella Azure-nätverket. Ett undernät är värd för de virtuella datorerna för att SAP HANA instanser. Det andra undernätet kör virtuella Jumpbox- eller Management-datorer som SAP HANA Studio, annan hanteringsprogramvara eller programprogramvara.

Viktigt

Ur funktion, men av prestandaskäl viktigare, stöds det inte att konfigurera virtuella Azure-nätverksutrustning i kommunikationsvägen mellan SAP-programmet och DBMS-skiktet i ett SAP NetWeaver-, Hybris- eller S/4HANA-baserat SAP-system. Kommunikationen mellan SAP-programlagret och DBMS-skiktet måste vara direkt. Begränsningen omfattar inte Azure ASG- och NSG-regler så länge asg- och NSG-reglerna tillåter direkt kommunikation. Ytterligare scenarier där NVA:er inte stöds finns i kommunikationsvägar mellan virtuella Azure-datorer som representerar Linux Pacemaker-klusternoder och SBD-enheter enligt beskrivningen i Hög tillgänglighet för SAP NetWeaverpå virtuella Azure-datorer på SUSE Linux Enterprise Server för SAP-program . Eller i kommunikationssökvägar mellan virtuella Azure-datorer och Windows Server SOFS konfigurerade enligt beskrivningen i Klustra en SAP ASCS/SCS-instanspå ett Windows-redundanskluster med hjälp av en filresurs i Azure . NVA:er i kommunikationsvägar kan enkelt dubblerat nätverksfördröjningen mellan två kommunikationspartner, kan begränsa dataflödet i kritiska sökvägar mellan SAP-programlagret och DBMS-skiktet. I vissa scenarier som observeras med kunder kan NVA:er orsaka att Pacemaker Linux-kluster misslyckas i fall där kommunikationen mellan Linux Pacemaker-klusternoderna behöver kommunicera med sin SBD-enhet via en NVA.

Viktigt

En annan design som INTE stöds är uppdelningen av SAP-programlagret och DBMS-skiktet i olika virtuella Azure-nätverk som inte är peer-peerade med varandra. Vi rekommenderar att du åtser SAP-programlagret och DBMS-lagret med hjälp av undernät i ett virtuellt Azure-nätverk i stället för att använda olika virtuella Azure-nätverk. Om du bestämmer dig för att inte följa rekommendationen och i stället åtse de två lagren i olika virtuella nätverk måste de två virtuella nätverken peer-användas. Tänk på att nätverkstrafiken mellan två peer-ade virtuella Azure-nätverk omfattas av överföringskostnader. Med den enorma datavolymen i många Terabyte utbytt mellan SAP-programlagret och DBMS-lagret kan betydande kostnader ackumuleras om SAP-programlagret och DBMS-skiktet är åtskilda mellan två peer-ade virtuella Azure-nätverk.

När du installerar de virtuella datorerna för SAP HANA måste de virtuella datorerna:

  • Två virtuella nätverkskort installerade: ett nätverkskort för att ansluta till hanteringsundernätet och ett nätverkskort för att ansluta från det lokala nätverket eller andra nätverk till SAP HANA-instansen på den virtuella Azure-datorn.
  • Statiska privata IP-adresser som distribueras för båda virtuella nätverkskorten.

Anteckning

Du bör tilldela statiska IP-adresser via Azure-metoder till enskilda virtuella nätverkskort. Du bör inte tilldela statiska IP-adresser i gästoperativsystemet till ett vNIC. Vissa Azure-tjänster som Azure Backup Service förlitar sig på det faktum att åtminstone det primära virtuella nätverkskortet är inställt på DHCP och inte på statiska IP-adresser. Se även dokumentet Felsöka säkerhetskopiering av virtuella Azure-datorer. Om du behöver tilldela flera statiska IP-adresser till en virtuell dator måste du tilldela flera virtuella nätverkskort till en virtuell dator.

För distributioner som är bestående måste du dock skapa en nätverksarkitektur för virtuella datacenter i Azure. Den här arkitekturen rekommenderar separationen av Azure VNet Gateway som ansluter till lokalt i ett separat azure-VNet. Det här separata virtuella nätverket ska vara värd för all trafik som lämnar antingen lokalt eller till Internet. Med den här metoden kan du distribuera programvara för gransknings- och loggningstrafik som kommer in i det virtuella datacentret i Azure i det här separata virtuella hubbnätverket. Så du har ett VNet som är värd för all programvara och alla 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 metoden för virtuella datacenter och relaterad Azure VNet-design.

Anteckning

Trafik som flödar mellan ett hubb-VNet och ett eker-VNet med hjälp av Azure VNet-peering är föremål för ytterligare kostnader. Baserat på dessa kostnader kan du behöva göra kompromisser mellan att köra en strikt nav- och ekernätverksdesign och köra flera Azure ExpressRoute-gatewayer som du ansluter till "ekrar" för att kringgå VNet-peering. Men Azure ExpressRoute gateways ger även ytterligare kostnader. Du kan också stöta på ytterligare kostnader för programvara från tredje part som du använder för loggning, granskning och övervakning av nätverkstrafik. Beroende på kostnaderna för datautbyte via VNet-peering på ena sidan och kostnader som skapas av ytterligare Azure ExpressRoute-gatewayer och ytterligare programvarulicenser kan du välja mikrosegmentering inom ett VNet genom att använda undernät som isoleringsenhet i stället för virtuella nätverk.

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 tilldelade statiska IP-adresser. Orsaken är att vissa konfigurationsattribut för HANA-referens-IP-adresser.

Azure-nätverkssäkerhetsgrupper (NSG: er) används för att dirigera trafik som dirigeras till SAP HANA instansen eller jumpboxen. NSG:erna och slutligen programsäkerhetsgrupperna är associerade SAP HANA undernätet och hanteringsundernätet.

Följande bild visar en översikt över ett ungefärligt distributionsschema för SAP HANA en hub- och spoke-arkitektur för virtuella nätverk:

Ungefärligt distributionsschema för SAP HANA

Om du 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 proxy för vidarebefordran. 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 azures inbyggda DNS-tjänster särskilt viktiga. Använd Azure NSG:er och Azure NVA:er för att styra och övervaka routningen från Internet till din Azure VNet-arkitektur i Azure. Följande bild visar ett ungefärligt schema för att SAP HANA utan en plats-till-plats-anslutning i en hubb- och ekerarkitektur för virtuella nätverk:

Ungefärligt distributionsschema för SAP HANA utan plats-till-plats-anslutning

En annan beskrivning av hur du använder Azure NVA:er för att kontrollera och övervaka åtkomst från Internet utan nav- och ekerarkitekturen för virtuella nätverk finns i artikeln Distribuera virtuella nätverkstillverk med hög tillgänglighet.

Konfigurera Azure-SAP HANA för 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 SAP HANA maskinvarukatalogen. En bockmarkering i kolumnen "Klustring" anger stöd för utskalning. Programtyp anger om OLAP-utskalning eller S/4HANA-utskalning stöds. Mer information om noder som certifierats i utskalning för var och en av de virtuella datorerna finns i informationen om posterna i den specifika VM-SKU:n som anges i SAP HANA maskinvarukatalogen.

De lägsta versionerna av operativsystemet för distribution av skalningskonfigurationer på virtuella Azure-datorer finns i informationen om posterna i den specifika VM-SKU:n som anges i SAP HANA maskinvarukatalog. I en OLAP-utskalningskonfiguration med n-nod fungerar en nod som huvudnod. De andra noderna upp till gränsen för certifieringen fungerar som arbetsnod. Ytterligare väntelägesnoder räknas inte in i antalet certifierade noder

Anteckning

Utskalningsdistributioner av virtuella Azure-datorer SAP HANA med väntelägesnoder är endast möjliga med hjälp Azure NetApp Files lagring. Ingen annan SAP HANA azure-lagring tillåter konfiguration av SAP HANA väntelägesnoder

För /hana/shared rekommenderar vi även att du använder Azure NetApp Files.

En typisk grundläggande design för en enskild nod i en utskalningskonfiguration kommer att se ut så här:

Diagram som visar en typisk grundläggande design för en enskild nod i en utskalningskonfiguration.

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.
  • 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 finns längre fram i det här dokumentet. För HANA-certifierad lagring som kan användas kan du läsa artikeln om SAP HANA lagringskonfigurationer för virtuella Azure-datorer.

När du ska ändra storlek på volymerna eller diskarna måste du kontrollera dokumentet SAP HANA TDI Storage Requirementsför den storlek som krävs beroende på antalet arbetsnoder. Dokumentet släpper en formel som du behöver tillämpa för att få den kapacitet som krävs för volymen

De andra designvillkoren som visas i grafiken för konfigurationen av en enskild nod för en utskalnings-SAP HANA virtuell dator är det virtuella nätverket eller bättre undernätskonfigurationen. 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 två olika virtuella nätverkskort är anslutna till den virtuella datorn. Båda de virtuella nätverkskorten finns i olika undernät och har två olika IP-adresser. 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 och metoder för att genomdriva tjänstkvalitet och kvoter på specifika virtuella nätverkskort. Det innebär att uppdelningen av klient-/programriktad kommunikation och kommunikation mellan noder inte öppnar några möjligheter att prioritera en trafikström framför den andra. I stället förblir separationen ett mått på säkerhet vid avskärmning av kommunikationen mellan noder i utskalningskonfigurationerna.

Anteckning

SAP rekommenderar att du separerar nätverkstrafik till klient-/programsidan och trafik mellan noder enligt beskrivningen i det här dokumentet. Vi rekommenderar därför att du sätter en arkitektur på plats som visas i den senaste grafiken. Kontakta även ditt säkerhets- och efterlevnadsteam för krav som avviker från rekommendationen

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

Grunder för utskalning av en enskild nod

Installera SAP HANA utskalning i Azure

När du installerar en utskalnings-SAP-konfiguration måste du utföra ungefärliga steg för att:

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

Installation av SAP HANA i utskalningskonfiguration

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

  • Installera SAP HANA huvudnoden enligt SAP:s dokumentation
  • Om du använder Azure Premium Storage- eller Ultra-disklagring med icke-delade diskar av /hana/data och /hana/log måste du ändra global.ini-filen och lägga till parametern "basepath_shared = nej" i global.ini-filen. Den här parametern SAP HANA kan köras i utskalning utan "delade" /hana/data- och /hana/log-volymer mellan noderna. Informationen finns dokumenterad i SAP-anteckningen #2080991. Om du använder NFS-volymer baserade på ANF för /hana/data och /hana/log behöver du inte göra den här ändringen
  • Efter den slutliga ändringen i parametern global.ini startar du om SAP HANA instansen
  • Lägg till ytterligare arbetsnoder. Se även https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.00/en-US/0d9fe701e2214e98ad4f8721f6558c34.html . Ange det interna nätverket för SAP HANA kommunikation mellan noder under installationen eller efteråt med exempelvis det lokala hdblcm. Mer detaljerad dokumentation finns även i SAP Note #2183363.

Information om hur du ställer in ett SAP HANA-skalningssystem med väntelägesnod på SUSE Linux beskrivs i detalj i Distribuera ett SAP HANA-skalningssystemmed en reservnod på virtuella Azure-datorer med hjälp av Azure NetApp Files på SUSE Linux Enterprise Server . Motsvarande dokumentation för Red Hat finns i artikeln Deploy a SAP HANA scale-out system with standby nodeon Azure VMs by using Azure NetApp Files on Red Hat Enterprise Linux .

SAP HANA dynamisk nivåindelad nivå 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 (se länkar till dokumentation om SAP HANA dynamisk nivåindelad nivå längre ned). Även om det inte finns någon skillnad i att installera produkten eller använda den, till exempel via SAP HANA Cockpit på en virtuell Azure-dator, finns det några viktiga objekt, som är obligatoriska för officiell support i Azure. Dessa viktiga punkter beskrivs nedan. I hela artikeln används förkortningen "DT 2.0" i stället för det fullständiga namnet Dynamic Tiering 2.0.

SAP HANA Dynamisk nivå 2.0 stöds inte av SAP BW eller S4HANA. De viktigaste användningsfallen just nu är interna HANA-program.

Översikt

Bilden nedan ger en översikt över DT 2.0-stöd för 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 vara installerat på en dedikerad virtuell Azure-dator. Den kanske inte körs på samma virtuella dator där SAP HANA körs
  • SAP HANA och virtuella DT 2.0-datorer måste distribueras inom samma virtuella Azure-nätverk
  • De SAP HANA virtuella datorerna och DT 2.0 måste distribueras med Azure-accelererat nätverk aktiverat
  • Storage för de virtuella DT 2.0-datorerna måste vara Azure Premium Storage
  • Flera Azure-diskar måste vara anslutna till den virtuella datorn DT 2.0
  • Du måste skapa en programvaru-raid-/stripe-volym (antingen via lvm eller mdadm) med striping över Azure-diskarna

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

SAP HANA DT 2.0-arkitekturöversikt

Dedikerad virtuell Azure-dator 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 SAP HANA DT 2.0:

  • M64-32 ms
  • E32sv3

Mer information om beskrivningen av VM-typ finns i Storlekar för 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 klokt att använda motsvarande VM-storlekar. Det finns dock ingen strikt regel om möjliga kombinationer. Det beror på den specifika kundarbetsbelastningen.

Rekommenderade konfigurationer är:

SAP HANA vm-typ DT 2.0 VM-typ
M128ms M64-32 ms
M128s M64-32 ms
M64ms E32sv3
M64s E32sv3

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

Azure-nätverk och SAP HANA DT 2.0

Installation av DT 2.0 på en dedikerad virtuell dator kräver nätverksdataflöde mellan den virtuella datorn DT 2.0 och den virtuella datorn SAP HANA minst 10 GB. Därför är det obligatoriskt att placera alla virtuella datorer i samma virtuella Azure-nätverk och aktivera Azure-accelererade nätverk.

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

Virtuell 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/sek per fysisk kärna. Om vi tittar på specifikationen för de två typerna av virtuella Azure-datorer, som stöds för DT 2.0, ser den maximala I/O-dataflödesgränsen för den virtuella datorn ut så här:

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

Du måste ansluta flera Azure-diskar till den virtuella datorn DT 2.0 och skapa en programvarur raid (striping) på OS-nivå för att uppnå den maximala gränsen för diskgenomflöde per virtuell dator. En enskild Azure-disk kan inte ange dataflödet för att nå maxgränsen för virtuella datorer i detta avseende. Azure Premium storage är obligatoriskt för att köra DT 2.0.

Beroende på storlekskraven finns det olika alternativ för att nå det maximala dataflödet för en virtuell dator. Här är möjliga datavolymdiskkonfigurationer för varje typ av DT 2.0-dator för att uppnå den övre dataflödesgränsen för virtuella datorer. Den virtuella datorn E32sv3 bör betraktas som en ingångsnivå 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–32 ms. Eftersom den virtuella datorn M64–32ms 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äckligt beroende på den kundspecifika arbetsbelastningen. Men för att vara på den säkra sidan valdes diskkonfigurationerna nedan för att garantera maximalt dataflöde:

VM-SKU Diskkonfiguration 1 Diskkonfiguration 2 Diskkonfiguration 3 Diskkonfiguration 4 Diskkonfiguration 5
M64-32 ms 4 x P50 -> 16 TB 4 x P40 -> 8 TB 5 x P30 -> 5 TB 7 x P20 -> 3,5 TB 8 x P15 -> 2 TB
E32sv3 3 x P50 -> 12 TB 3 x P40 -> 6 TB 4 x P30 -> 4 TB 5 x P20 -> 2,5 TB 6 x P15 -> 1,5 TB

Särskilt om arbetsbelastningen är läsintensiv kan det öka I/O-prestandan för att aktivera "skrivskyddade" Azure-värdcache som rekommenderas för datavolymerna i databasprogramvaran. För transaktionsloggen måste Azure-värddiskcachen 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 Azure-disktyper beroende på kostnad och dataflödeskrav. För loggvolymen krävs högt I/O-dataflöde. Om du använder vm-typen M64-32ms är det obligatoriskt att aktivera Skrivningsaccelerator. Azure Skrivningsaccelerator ger optimal diskskrivningssvarstid för transaktionsloggen (endast tillgängligt för M-serien). Det finns några saker att tänka på, t.ex. det maximala antalet diskar per typ av virtuell dator. Information om Skrivningsaccelerator finns på sidan för Azure Skrivningsaccelerator

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

datavolymstorlek och disktyp loggvolym och disktyp config 1 loggvolym och disktyp config 2
4 x P50 -> 16 TB 5 x P20 -> 2,5 TB 3 x P30 -> 3 TB
6 x P15 -> 1,5 TB 4 x P6 -> 256 GB 1 x P15 -> 256 GB

Precis som SAP HANA utskalning måste katalogen /hana/shared delas mellan den virtuella SAP HANA-datorn och den virtuella datorn DT 2.0. Samma arkitektur som för SAP HANA med dedikerade virtuella datorer, som fungerar som en NFS-server med hög tillgång rekommenderas. Identisk design kan användas för att tillhandahålla en delad säkerhetskopieringsvolym. Men det är upp till kunden om ha varit 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.

Å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 på virtuella Azure-datorer.

Kvarvarande och återställda åtgärder på virtuella Azure-datorer

I följande dokument beskrivs hur du kommer tillbaka till och SAP HANA distributionen:

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

En viktig funktion i det offentliga Azure-molnet är att du bara debiteras för dina beräkningsminuter. När du till exempel stänger av en virtuell dator som kör SAP HANA debiteras du bara 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 SAP HANA startas den virtuella datorn om med dess 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åll den privata och statiska IP-adressen för den virtuella dator som SAP HANA i SAProuter-konfigurationen.
  • Konfigurera NSG för undernätet 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 en SAP-router för den virtuella datorn med SAP HANA måste du installera komponenten. Installera SAProuter på en separat virtuell dator i hanteringsundernätet. Följande bild visar ett ungefärligt schema för att SAP HANA utan plats-till-plats-anslutning och med SAProuter:

Ungefärligt distributionsschema för SAP HANA utan plats-till-plats-anslutning och SAProuter

Se till att installera SAProuter på en separat virtuell dator och inte på din virtuella Jumpbox-dator. Den separata virtuella datorn måste ha en statisk IP-adress. Om du vill ansluta din SAProuter till SAProuter som finns i SAP kontaktar du SAP för en IP-adress. (SAProuter som finns i 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. Den enda nödvändiga porten i konfigurationsinställningarna är TCP-port 3299.

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

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

Om du kör en SUSE Linux Enterprise Server Red Hat kan du upprätta ett pacemakerkluster med STONITH-enheter. Du kan använda enheterna för att konfigurera en SAP HANA 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 i listan