Configuraties en bewerkingen van SAP HANA-infrastructuur in Azure

Dit document bevat richtlijnen voor het configureren van de Azure-infrastructuur en SAP HANA-systemen die zijn geïmplementeerd op systeemeigen virtuele Azure-machines (VM's). Het document bevat ook configuratiegegevens voor SAP HANA uitschalen voor de M128s VM-SKU. Dit document is niet bedoeld ter vervanging van de sap-standaarddocumentatie, die de volgende inhoud bevat:

Vereisten

Als u deze handleiding wilt gebruiken, hebt u basiskennis nodig van de volgende Azure-onderdelen:

Zie de sectie SAP on Azure van de Azure-documentatie voor meer informatie over SAP NetWeaver en andere SAP-onderdelen in Azure.

Basisoverwegingen bij het instellen

In de volgende secties worden basisoverwegingen beschreven voor het implementeren van SAP HANA-systemen op Azure-VM's.

Verbinding maken in virtuele Azure-machines

Zoals beschreven in de planningshandleiding voor virtuele Azure-machines,zijn er twee basismethoden om verbinding te maken met Azure-VM's:

  • Verbinding maken via internet en openbare eindpunten op een jump-VM of op de VM met SAP HANA.
  • Verbinding maken via een VPN of Azure ExpressRoute.

Site-naar-site-connectiviteit via VPN of ExpressRoute is nodig voor productiescenario's. Dit type verbinding is ook nodig voor niet-productiescenario's die worden gebruikt in productiescenario's waarin SAP-software wordt gebruikt. In de volgende afbeelding ziet u een voorbeeld van cross-site-connectiviteit:

Cross-site-connectiviteit

Azure VM-typen kiezen

De Azure VM-typen die kunnen worden gebruikt voor productiescenario's worden vermeld in de SAP-documentatie voor IAAS. Voor niet-productiescenario's is een breder scala aan native Azure-VM-typen beschikbaar.

Notitie

Gebruik voor niet-productiescenario's de VM-typen die worden vermeld in de SAP-notitie #1928533. Voor het gebruik van Azure-VM's voor productiescenario's, controleert u op SAP HANA gecertificeerde VM's in de lijst met door SAP gepubliceerde gecertificeerde IaaS-platforms.

Implementeer de VM's in Azure met behulp van:

  • De Azure-portal.
  • Azure PowerShell cmdlets.
  • De Azure CLI.

U kunt ook een volledig geïnstalleerd SAP HANA implementeren op de Azure VM-services via het SAP Cloud-platform. Het installatieproces wordt beschreven in SAP S/4HANA of BW/4HANA implementeren in Azure of met de automatisering die is uitgebracht op GitHub.

Belangrijk

Als u virtuele M208xx_v2 wilt gebruiken, moet u voorzichtig zijn met het selecteren van uw Linux-afbeelding in de azure VM-afbeeldingengalerie. Lees het artikel Voor geheugen geoptimaliseerde grootte van virtuele machines om de details te lezen.

Storage configuratie voor SAP HANA

Als u opslagconfiguraties en opslagtypen wilt gebruiken met SAP HANA in Azure, leest u het document SAP HANA azure virtual machine storage configurations (Opslagconfiguraties voor virtuele Azure-machines)

Virtuele Azure-netwerken instellen

Wanneer u site-naar-site-verbinding hebt met Azure via VPN of ExpressRoute, moet u ten minste één virtueel Azure-netwerk hebben dat via een virtuele gateway is verbonden met het VPN- of ExpressRoute-circuit. In eenvoudige implementaties kan de virtuele gateway ook worden geïmplementeerd in een subnet van het virtuele Azure-netwerk (VNet) dat de SAP HANA-exemplaren host. Als u SAP HANA, maakt u twee extra subnetten binnen het virtuele Azure-netwerk. Eén subnet host de VM's om de SAP HANA uit te voeren. In het andere subnet worden Jumpbox- of beheer-VM's uitgevoerd om SAP HANA Studio, andere beheersoftware of uw toepassingssoftware te hosten.

Belangrijk

Niet-functionaliteit, maar belangrijker uit prestatieoverwegingen, wordt het niet ondersteund om virtuele Azure-netwerkapparaten te configureren in het communicatiepad tussen de SAP-toepassing en de DBMS-laag van een SAP NetWeaver-, Hybris- of S/4HANA-SAP-systeem. De communicatie tussen de SAP-toepassingslaag en de DBMS-laag moet direct zijn. De beperking omvat geen Azure ASG- en NSG-regels zolang deze ASG- en NSG-regels directe communicatie toestaan. Andere scenario's waarin NNA's niet worden ondersteund, vindt u in communicatiepaden tussen Azure-VM's die Linux Pacemaker-clusterknooppunten en SBD-apparaten vertegenwoordigen, zoals beschreven in Hoge beschikbaarheid voor SAP NetWeaver op Azure-VM's op SUSE Linux Enterprise Server voor SAP-toepassingen. Of in communicatiepaden tussen Azure-VM's en Windows Server SOFS ingesteld zoals beschreven in Cluster an SAP ASCS/SCS instance on a Windows failover cluster by using a file share in Azure (Een SAP ASCS/SCS-exemplaar op een Windows-failoverclusterclusteren met behulp van een bestands share in Azure ). NBA's in communicatiepaden kunnen eenvoudig de netwerklatentie tussen twee communicatiepartners verdubbelen, kunnen de doorvoer in kritieke paden tussen de SAP-toepassingslaag en de DBMS-laag beperken. In sommige scenario's waar klanten rekening mee houden, kunnen NVA's ertoe leiden dat Pacemaker Linux-clusters mislukken in gevallen waarin communicatie tussen de knooppunten van het Linux Pacemaker-cluster met hun SBD-apparaat moet communiceren via een NVA.

Belangrijk

Een ander ontwerp dat NIET wordt ondersteund, is de scheiding van de SAP-toepassingslaag en de DBMS-laag in verschillende virtuele Azure-netwerken die niet met elkaar zijn peerd. Het is raadzaam om de SAP-toepassingslaag en DBMS-laag te scheiden met behulp van subnetten in een virtueel Azure-netwerk in plaats van verschillende virtuele Azure-netwerken te gebruiken. Als u besluit de aanbeveling niet te volgen en in plaats daarvan de twee lagen in een ander virtueel netwerk te scheiden, moeten de twee virtuele netwerken worden peered. Let op: netwerkverkeer tussen twee virtuele Azure-peernetwerken is onderhevig aan overdrachtskosten. Met het enorme gegevensvolume in veel Terabytes dat tussen de SAP-toepassingslaag en de DBMS-laag wordt uitgewisseld, kunnen aanzienlijke kosten worden gecumuleerd als de SAP-toepassingslaag en DBMS-laag zijn gescheiden tussen twee virtuele Azure-netwerken met peering.

Wanneer u de VM's installeert om SAP HANA uit te voeren, hebben de VM's het volgende nodig:

  • Er zijn twee virtuele NIC's geïnstalleerd: één NIC om verbinding te maken met het beheersubnet en één NIC om vanuit het on-premises netwerk of andere netwerken verbinding te maken met het SAP HANA-exemplaar in de Azure-VM.
  • Statische privé IP-adressen die zijn geïmplementeerd voor beide virtuele NIC's.

Notitie

U moet statische IP-adressen via Azure toewijzen aan afzonderlijke vNIC's. Wijs geen statische IP-adressen binnen het gast-besturingssysteem toe aan een vNIC. Sommige Azure-services zoals Azure Backup Service zijn afhankelijk van het feit dat ten minste de primaire vNIC is ingesteld op DHCP en niet op statische IP-adressen. Zie ook het document Troubleshoot Azure virtual machine backup (Problemen met back-ups van virtuele Azure-machines oplossen). Als u meerdere statische IP-adressen moet toewijzen aan een VM, moet u meerdere vNIC's toewijzen aan een VM.

Voor implementaties die duurzaam zijn, moet u echter een virtuele datacenternetwerkarchitectuur maken in Azure. Deze architectuur raadt de scheiding aan van de Azure-VNet Gateway verbinding maakt met on-premises in een afzonderlijk Azure-VNet. Dit afzonderlijke VNet moet als host dienen voor al het verkeer dat naar on-premises of internet verlaat. Met deze aanpak kunt u software implementeren voor het controleren en registreren van verkeer dat het virtuele datacenter in Azure binnenkomt in dit afzonderlijke hub-VNet. U hebt dus één VNet dat als host voor alle software en configuraties die betrekking heeft op in- en uitgaand verkeer naar uw Azure-implementatie.

De artikelen Azure Virtual Datacenter: A Network Perspective en Azure Virtual Datacenter en Enterprise Control Plane geven meer informatie over de benadering van virtuele datacenters en het bijbehorende Azure VNet-ontwerp.

Notitie

Verkeer dat tussen een hub-VNet en een spoke-VNet stroomt met behulp van Azure VNet-peering, wordt onderworpen aan extra kosten. Op basis van deze kosten moet u mogelijk compromissen sluiten tussen het uitvoeren van een strikt hub en spoke-netwerkontwerp en het uitvoeren van meerdere Azure ExpressRoute-gateways die u verbindt met 'spokes' om VNet-peering te omzeilen. Met Azure ExpressRoute gateways worden echter ook extra kosten in rekening brengen. Er kunnen ook extra kosten in rekening worden brengen voor software van derden die u gebruikt voor logboekregistratie, controle en bewaking van netwerkverkeer. Afhankelijk van de kosten voor gegevensuitwisseling via VNet-peering aan de ene zijde en de kosten die worden gemaakt door extra Azure ExpressRoute Gateways en aanvullende softwarelicenties, kunt u kiezen voor microsegmentatie binnen één VNet door subnetten te gebruiken als isolatie-eenheid in plaats van VNets.

Zie IP-adrestypen en toewijzingsmethoden in Azure voor een overzicht van de verschillende methoden voor het toewijzen van IP-adressen.

Voor VM's SAP HANA, moet u werken met toegewezen statische IP-adressen. Reden is dat sommige configuratiekenmerken voor HANA-referentie-IP-adressen.

Azure-netwerkbeveiligingsgroepen (NSG's) worden gebruikt om verkeer te sturen dat wordt doorgeleid naar het SAP HANA-exemplaar of de jumpbox. De NSG's en uiteindelijke toepassingsbeveiligingsgroepen worden gekoppeld aan het SAP HANA subnet en het beheersubnet.

In de volgende afbeelding ziet u een overzicht van een ruw implementatieschema voor SAP HANA een hub en spoke VNet-architectuur:

Ruw implementatieschema voor SAP HANA

Als u SAP HANA wilt implementeren in Azure zonder een site-naar-site-verbinding, wilt u het SAP HANA-exemplaar nog steeds afschermen van het openbare internet en verbergen achter een doorgestuurde proxy. In dit eenvoudige scenario is de implementatie afhankelijk van de ingebouwde DNS-services van Azure om hostnamen om te draaien. In een complexere implementatie waarbij openbare IP-adressen worden gebruikt, zijn ingebouwde DNS-services van Azure met name belangrijk. Gebruik Azure NSG's en Azure N NVA's om de routering van internet naar uw Azure VNet-architectuur in Azure te controleren. In de volgende afbeelding ziet u een ruw schema voor het implementeren van SAP HANA zonder site-naar-site-verbinding in een hub-and-spoke-VNet-architectuur:

Ruw implementatieschema voor SAP HANA zonder een site-naar-site-verbinding

Een andere beschrijving van het gebruik van Azure NNA's voor het controleren en controleren van de toegang vanaf internet zonder de hub en spoke VNet-architectuur vindt u in het artikel Deploy highly available network virtual appliances (Virtuele netwerkapparaten met hoge beschikbare netwerkapparaten implementeren).

Azure-infrastructuur configureren voor SAP HANA uitschalen

Als u wilt weten welke Azure-VM-typen zijn gecertificeerd voor uitschalen van OLAP of uitschalen van S/4HANA, raadpleegt u de hardwaremap SAP HANA azure-hardware. Een vinkje in de kolom Clustering geeft ondersteuning voor uitschalen aan. Toepassingstype geeft aan of uitschalen van OLAP of S/4HANA-uitschalen wordt ondersteund. Voor meer informatie over knooppunten die zijn gecertificeerd in uitschalen voor elk van de VM's, controleert u de details van de vermeldingen in de specifieke VM-SKU die wordt vermeld in de map SAP HANA hardware.

De minimale versie van het besturingssysteem voor het implementeren van scale-outconfiguraties in Azure-VM's, controleert u de details van de vermeldingen in de specifieke VM-SKU die wordt vermeld in de map SAP HANA hardware. Van een OLAP-uitschaalconfiguratie met n-knooppunt functioneert één knooppunt als hoofd-knooppunt. De andere knooppunten tot de limiet van de certificering fungeren als werkknooppunt. Extra stand-byknooppunten tellen niet mee voor het aantal gecertificeerde knooppunten

Notitie

Azure VM scale-out implementaties van SAP HANA met stand-by-knooppunt zijn alleen mogelijk met behulp van Azure NetApp Files opslag. Er zijn geen andere SAP HANA gecertificeerde Azure-opslag die de configuratie van SAP HANA stand-by-knooppunten toestaat

Voor /hana/shared wordt ook het gebruik van Azure NetApp Files.

Een typisch basisontwerp voor één knooppunt in een scale-out configuratie ziet er als volgende uit:

Diagram met een typisch basisontwerp voor één knooppunt in een scale-out configuratie.

De basisconfiguratie van een VM-knooppunt voor SAP HANA uitschalen ziet er als volgende uit:

  • Voor /hana/shared gebruikt u de native NFS-service die wordt geleverd via Azure NetApp Files.
  • Alle andere schijfvolumes worden niet gedeeld tussen de verschillende knooppunten en zijn niet gebaseerd op NFS. Installatieconfiguraties en stappen voor scale-out HANA-installaties met niet-gedeelde /hana/data en /hana/log worden verderop in dit document be gegeven. Raadpleeg het artikel SAP HANA azure virtual machine storage configurations (Opslagconfiguraties voor virtuele Azure-machines) voorgecertificeerde HANA-opslag die kan worden gebruikt.

Als u de grootte van de volumes of schijven wilt wijzigen, moet u het document SAP HANA TDI Storage Requirementscontroleren op de vereiste grootte, afhankelijk van het aantal werkknooppunten. In het document wordt een formule uitgebracht die u moet toepassen om de vereiste capaciteit van het volume op te halen

De andere ontwerpcriteria die worden weergegeven in de grafische weergave van de configuratie van één knooppunt voor een scale-out SAP HANA VM is het VNet, of beter nog, de subnetconfiguratie. SAP raadt ten zeerste aan het client-/toepassingsverkeer te scheiden van de communicatie tussen de HANA-knooppunten. Zoals u in de afbeeldingen kunt zien, wordt dit doel bereikt door twee verschillende vNIC's aan de VM te koppelen. Beide vNIC's zijn in verschillende subnetten, hebben twee verschillende IP-adressen. Vervolgens kunt u de verkeersstroom met routeringsregels bepalen met behulp van NSG's of door de gebruiker gedefinieerde routes.

Met name in Azure zijn er geen methoden en methoden om de kwaliteit van de service en quota op specifieke vNIC's af te dwingen. Als gevolg hiervan biedt de scheiding tussen client-/toepassingscommunicatie en intra-knooppuntcommunicatie geen mogelijkheden om prioriteit te geven aan de ene verkeersstroom boven de andere. In plaats daarvan blijft de scheiding een maatstaf voor de beveiliging bij het afschermen van de communicatie tussen knooppunts van de scale-out configuraties.

Notitie

SAP raadt aan netwerkverkeer te scheiden naar de client-/toepassingszijde en intra-knooppuntverkeer, zoals beschreven in dit document. Daarom is het raadzaam om een architectuur te gebruiken zoals wordt weergegeven in de laatste grafische weergaven. Neem ook contact op met uw beveiligings- en nalevingsteam voor vereisten die afwijken van de aanbeveling

Vanuit het oogpunt van netwerken ziet de minimaal vereiste netwerkarchitectuur er als volgende uit:

Basisbeginselen van uitschalen van één knooppunt

Uitschalen SAP HANA Azure installeren

Als u een sap-configuratie met uitschalen installeert, moet u de volgende ruwe stappen uitvoeren:

  • Nieuwe Azure VNet-infrastructuur implementeren of aanpassen
  • De nieuwe VM's implementeren met behulp van Azure Managed Premium Storage, Ultra Disk Volumes en/of NFS-volumes op basis van ANF
    • Pas netwerkroutering aan om ervoor te zorgen dat bijvoorbeeld de communicatie tussen knooppunt tussen VM's niet wordt gerouteerd via een NVA.
  • Installeer het SAP HANA hoofd-knooppunt.
  • Configuratieparameters van het SAP HANA hoofd-knooppunt aanpassen
  • Doorgaan met de installatie van de SAP HANA werkknooppunten

Installatie van SAP HANA in scale-out configuratie

Wanneer uw Azure VM-infrastructuur wordt geïmplementeerd en alle andere voorbereidingen zijn uitgevoerd, moet u de SAP HANA scale-out configuraties installeren in deze stappen:

  • Installeer het SAP HANA hoofd-knooppunt volgens de documentatie van SAP
  • In het geval van het gebruik van Azure Premium Storage of Ultra Disk Storage met niet-gedeelde schijven van /hana/data en /hana/log, moet u het global.ini-bestand wijzigen en de parameter 'basepath_shared = nee' toevoegen aan het global.ini-bestand. Met deze parameter SAP HANA worden uitgevoerd in scale-out zonder 'gedeelde' /hana/data en /hana/log-volumes tussen de knooppunten. Details worden beschreven in SAP Note #2080991. Als u NFS-volumes gebruikt op basis van ANF voor /hana/data en /hana/log, hoeft u deze wijziging niet aan te brengen
  • Na de uiteindelijke wijziging in de parameter global.ini start u het SAP HANA opnieuw
  • Voeg extra werkknooppunten toe. Zie ook https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.00/en-US/0d9fe701e2214e98ad4f8721f6558c34.html . Geef het interne netwerk voor SAP HANA communicatie tussen knooppunt tijdens de installatie of daarna met behulp van bijvoorbeeld de lokale hdblcm. Zie ook SAP Note #2183363 voor meer #2183363.

Meer informatie over het instellen van een SAP HANA-scale-outsysteem met stand-by-knooppunt in SUSE Linux wordt gedetailleerd beschreven in Deploy a SAP HANA scale-out system with standby node on Azure VMs by using Azure NetApp Files on SUSE Linux Enterprise Server (Een SAP HANA-scale-outsysteemimplementeren met stand-by-knooppunt op virtuele Azure-VM's met behulp van Azure NetApp Files op SUSE Linux Enterprise Server . Equivalente documentatie voor Red Hat vindt u in het artikel Deploy a SAP HANA scale-out system with standby nodeon Azure VMs by using Azure NetApp Files on Red Hat Enterprise Linux .

SAP HANA Dynamic Tiering 2.0 voor virtuele Azure-machines

Naast de SAP HANA-certificeringen op VM's uit de Azure M-serie wordt SAP HANA Dynamic Tiering 2.0 ook ondersteund op Microsoft Azure (zie de koppelingen naar de documentatie voor dynamische lagen van SAP HANA verderop). Hoewel er geen verschil is in het installeren of gebruiken van het product, bijvoorbeeld via SAP HANA Cockpit in een virtuele Azure-machine, zijn er enkele belangrijke items die verplicht zijn voor officiële ondersteuning in Azure. Deze belangrijke punten worden hieronder beschreven. In het hele artikel wordt de afkorting DT 2.0 gebruikt in plaats van de volledige naam Dynamic Tiering 2.0.

SAP HANA Dynamische laag 2.0 wordt niet ondersteund door SAP BW of S4HANA. De belangrijkste use cases op dit moment zijn native HANA-toepassingen.

Overzicht

In de onderstaande afbeelding ziet u een overzicht van DT 2.0-ondersteuning op Microsoft Azure. Er is een reeks verplichte vereisten die moeten worden gevolgd om te voldoen aan de officiële certificering:

  • DT 2.0 moet worden geïnstalleerd op een toegewezen Azure-VM. Het kan niet worden uitgevoerd op dezelfde VM waarop SAP HANA wordt uitgevoerd
  • SAP HANA- en DT 2.0-VM's moeten worden geïmplementeerd in hetzelfde Azure-Vnet
  • De SAP HANA en DT 2.0-VM's moeten worden geïmplementeerd met versneld Netwerken van Azure ingeschakeld
  • Storage type voor de DT 2.0-VM's moet Azure-Premium Storage
  • Er moeten meerdere Azure-schijven worden gekoppeld aan de DT 2.0-VM
  • Het is vereist om een software-raid/-striped volume te maken (via lvm of m²m) met behulp van striping over de Azure-schijven

Meer informatie wordt uitgelegd in de volgende secties.

SAP HANA architectuuroverzicht van DT 2.0

Toegewezen Azure VM voor SAP HANA DT 2.0

Op Azure IaaS wordt DT 2.0 alleen ondersteund op een toegewezen VM. Het is niet toegestaan om DT 2.0 uit te voeren op dezelfde Azure-VM waarop het HANA-exemplaar wordt uitgevoerd. Er kunnen in eerste instantie twee VM-typen worden gebruikt om SAP HANA DT 2.0 uit te voeren:

  • M64-32 ms
  • E32sv3

Zie Azure VM-grootten - geheugen voor meer informatie over de beschrijving van het VM-type

Gezien het basisprincipe van DT 2.0, dat gaat over het offloaden van 'warme' gegevens om kosten te besparen, is het zinvol om bijbehorende VM-grootten te gebruiken. Er is echter geen strikte regel met betrekking tot de mogelijke combinaties. Dit is afhankelijk van de specifieke workload van de klant.

Aanbevolen configuraties zijn:

SAP HANA VM-type Type DT 2.0-VM
M128ms M64-32 ms
M128s M64-32 ms
M64ms E32sv3
M64s E32sv3

Alle combinaties van SAP HANA-gecertificeerde VM's uit de M-serie met ondersteunde DT 2.0-VM's (M64-32ms en E32sv3) zijn mogelijk.

Azure-netwerken en SAP HANA DT 2.0

Voor het installeren van DT 2.0 op een toegewezen VM is netwerkdoorvoer tussen de DT 2.0-VM en de SAP HANA-VM van minimaal 10 GB vereist. Daarom is het verplicht om alle VM's binnen hetzelfde Azure-Vnet te plaatsen en versneld Netwerken van Azure in te stellen.

Zie aanvullende informatie over versneld netwerken in Azure Een Azure-VM maken met versneld netwerken met behulp van Azure CLI

VM Storage voor SAP HANA DT 2.0

Volgens de richtlijnen van DT 2.0 best practice moet de I/O-doorvoer van de schijf minimaal 50 MB per seconde per fysieke kern zijn. Bekijk de specificatie voor de twee Azure-VM-typen, die worden ondersteund voor DT 2.0. De maximale I/O-doorvoerlimiet van de schijf voor de VM ziet er als volgende uit:

  • E32sv3: 768 MB per seconde (niet-gecached), wat een verhouding van 48 MB per seconde per fysieke kern betekent
  • M64-32 ms: 1000 MB per seconde (niet-gecached), wat een verhouding van 62,5 MB/sec per fysieke kern betekent

Het is vereist om meerdere Azure-schijven te koppelen aan de DT 2.0-VM en een software-raid (striping) op besturingssysteemniveau te maken om de maximale limiet van schijfdoorvoer per VM te bereiken. Eén Azure-schijf kan in dit opzicht niet de doorvoer leveren om de maximale VM-limiet te bereiken. Azure Premium-opslag is verplicht om DT 2.0 uit te voeren.

  • Meer informatie over beschikbare Azure-schijftypen vindt u op de pagina Een schijftype selecteren voor Azure IaaS-VM's - beheerde schijven
  • Meer informatie over het maken van software-raid via mpagem vindt u op de pagina Software RAID configureren op een Linux-VM
  • Meer informatie over het configureren van LVM voor het maken van een striped volume voor maximale doorvoer vindt u op de pagina LVM configureren op een virtuele machine met Linux

Afhankelijk van de groottevereisten zijn er verschillende opties om de maximale doorvoer van een VM te bereiken. Hier zijn mogelijke schijfconfiguraties voor gegevensvolumes voor elk type DT 2.0-VM om de bovengrens voor de VM-doorvoer te bereiken. De VM E32sv3 moet worden beschouwd als een toegangsniveau voor kleinere workloads. Als blijkt dat de VM niet snel genoeg is, kan het nodig zijn om de VM te veranderen in M64-32 ms. Omdat de virtuele M64-32ms-VM veel geheugen heeft, bereikt de I/O-belasting mogelijk niet de limiet, met name voor leesintensieve werkbelastingen. Daarom is het mogelijk dat minder schijven in de stripe-set voldoende zijn, afhankelijk van de specifieke workload van de klant. Maar om aan de veilige kant te staan, zijn de onderstaande schijfconfiguraties gekozen om de maximale doorvoer te garanderen:

VM-SKU Schijf config 1 Schijf config 2 Schijf config 3 Schijf config 4 Schijf config 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

Met name als de workload lees-intensief is, kan dit de I/O-prestaties verbeteren door azure-hostcache 'alleen-lezen' in te zetten, zoals aanbevolen voor de gegevensvolumes van databasesoftware. Voor het transactielogboek moet de schijfcache van de Azure-host 'geen' zijn.

Met betrekking tot de grootte van het logboekvolume is een aanbevolen startpunt een heuristiek van 15% van de gegevensgrootte. Het maken van het logboekvolume kan worden uitgevoerd met behulp van verschillende Azure-schijftypen, afhankelijk van de kosten- en doorvoervereisten. Voor het logboekvolume is een hoge I/O-doorvoer vereist. In het geval van het gebruik van het VM-type M64-32ms is het verplicht om in te Write Accelerator. Azure Write Accelerator optimale schrijflatentie voor de schijf voor het transactielogboek (alleen beschikbaar voor de M-serie). Er zijn enkele items die u moet overwegen, zoals het maximum aantal schijven per VM-type. Meer informatie over Write Accelerator vindt u op de pagina Azure Write Accelerator

Hier zijn enkele voorbeelden van het aanpassen van de omvang van het logboekvolume:

gegevensvolumegrootte en schijftype logboekvolume en schijftype configuratie 1 configuratie van logboekvolume en schijftype 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

Net als SAP HANA uitschalen, moet de map /hana/shared worden gedeeld tussen de SAP HANA-VM en de DT 2.0-VM. Dezelfde architectuur als voor SAP HANA uitschalen met behulp van toegewezen VM's, die fungeren als een NFS-server met hoge beschikbare gegevens. Om een gedeeld back-upvolume te bieden, kan het identieke ontwerp worden gebruikt. Maar het is aan de klant of hoge capaciteit nodig is of dat het voldoende is om alleen een toegewezen VM met voldoende opslagcapaciteit te gebruiken om te fungeren als een back-upserver.

Bewerkingen voor het implementeren van SAP HANA op Virtuele Azure-VM's

In de volgende secties worden enkele bewerkingen beschreven die betrekking hebben op het implementeren van SAP HANA-systemen op Virtuele Azure-VM's.

Back-up- en herstelbewerkingen op virtuele Azure-VM's

In de volgende documenten wordt beschreven hoe u een back-up kunt maken van uw SAP HANA implementatie:

VM's met een SAP HANA

Een belangrijke functie van de openbare Azure-cloud is dat er alleen kosten in rekening worden gebracht voor uw rekenminuten. Wanneer u bijvoorbeeld een VM met SAP HANA, wordt u alleen gefactureerd voor de opslagkosten gedurende die periode. Een andere functie is beschikbaar wanneer u statische IP-adressen opgeeft voor uw VM's in uw eerste implementatie. Wanneer u een virtuele SAP HANA opnieuw opstart, wordt de VM opnieuw opgestart met de voorgaande IP-adressen.

SAProprogramm gebruiken voor externe SAP-ondersteuning

Als u een site-naar-site-verbinding hebt tussen uw on-premises locaties en Azure en u SAP-onderdelen gebruikt, bent u waarschijnlijk al met SAProprogramm. In dit geval voltooit u de volgende items voor externe ondersteuning:

  • Behoud het privé- en statische IP-adres van de VM die als host SAP HANA in de SAProloft-configuratie.
  • Configureer de NSG van het subnet dat als host voor de HANA-VM wordt gebruikt om verkeer via TCP/IP-poort 3299 toe te staan.

Als u via internet verbinding maakt met Azure en u hebt geen SAP-router voor de VM met SAP HANA, moet u het onderdeel installeren. Installeer SAProloft in een afzonderlijke virtuele machine in het beheersubnet. In de volgende afbeelding ziet u een ruw schema voor het implementeren SAP HANA zonder site-naar-site-verbinding en met SAProprogramm:

Ruw implementatieschema voor SAP HANA zonder site-naar-site-verbinding en SAPro diagram

Zorg ervoor dat u SAProprogramm installeert in een afzonderlijke VM en niet in uw Jumpbox-VM. De afzonderlijke VM moet een statisch IP-adres hebben. Neem contact op met SAP voor een IP-adres om uw SAPropunt te verbinden met de SAProprop die wordt gehost door SAP. (De SAProloft die wordt gehost door SAP is het equivalent van het SAProloft-exemplaar dat u op uw VM installeert.) Gebruik het IP-adres van SAP om uw SAPro exemplaren te configureren. In de configuratie-instellingen is TCP-poort 3299 de enige benodigde poort.

Zie de SAP-documentatievoor meer informatie over het instellen en onderhouden van externe ondersteuningsverbindingen via SAProcentrum.

Hoge beschikbaarheid met SAP HANA in azure-VM's

Als u een cluster SUSE Linux Enterprise Server Of Red Hat, kunt u een Pacemaker-cluster met STONITH-apparaten tot stand te laten komen. U kunt de apparaten gebruiken om een SAP HANA in te stellen die gebruikmaakt van synchrone replicatie met HANA-systeemreplicatie en automatische failover. Meer informatie vindt u in de sectie Volgende stappen.

Volgende stappen

Vertrouwd raken met de vermelde artikelen