Configuraties van SAP HANA in virtuele Azure-machineopslag

Artikel
03/20/2024

Azure biedt verschillende typen opslag die geschikt zijn voor Azure-VM's waarop SAP HANA wordt uitgevoerd. De door SAP HANA gecertificeerde Azure-opslagtypen die kunnen worden overwogen voor sap HANA-implementaties, zoals:

Azure Premium SSD of Premium Storage v1/v2
Ultraschijven
Azure NetApp Files

Zie het artikel Azure Storage-typen voor SAP-workload en selecteer een schijftype voor meer informatie over deze schijftypen

Azure biedt twee implementatiemethoden voor VHD's in Azure Standard en Premium Storage v1/v2. We verwachten dat u profiteert van azure managed disk voor Azure-blokopslagimplementaties.

Raadpleeg de Azure-documentatie voor beheerde schijven voor een lijst met opslagtypen en hun SLA's in IOPS en opslagdoorvoer.

Belangrijk

Onafhankelijk van het gekozen Azure-opslagtype moet het bestandssysteem dat wordt gebruikt voor die opslag worden ondersteund door SAP voor het specifieke besturingssysteem en DBMS. Sap-ondersteuningsnotitie #2972496 bevat de ondersteunde bestandssystemen voor verschillende besturingssystemen en databases, waaronder SAP HANA. Dit geldt voor alle volumes die SAP HANA kan openen voor lezen en schrijven voor elke taak. Met name het gebruik van NFS in Azure voor SAP HANA zijn aanvullende beperkingen van NFS-versies van toepassing, zoals verderop in dit artikel wordt vermeld

De minimale door SAP HANA gecertificeerde voorwaarden voor de verschillende opslagtypen zijn:

Azure Premium Storage v1 - /hana/log moet worden ondersteund door Azure Write Accelerator. Het /hana/gegevensvolume kan worden geplaatst op Premium Storage v1 zonder Azure Write Accelerator of op Ultra Disk. Azure Premium Storage v2 of Azure Premium SSD v2 biedt geen ondersteuning voor het gebruik van Azure Write Accelerator
Azure Ultra-schijf ten minste voor het volume /hana/log . Het /hana/gegevensvolume kan worden geplaatst op premium-opslag v1/v2 zonder Azure Write Accelerator of om sneller opnieuw op te starten ultraschijf
NFS v4.1-volumes boven op Azure NetApp Files voor /hana/log en /hana/data. Het volume van /hana/shared kan gebruikmaken van het NFS v3- of NFS v4.1-protocol

Op basis van ervaring met klanten hebben we de ondersteuning gewijzigd voor het combineren van verschillende opslagtypen tussen /hana/data en /hana/log. Het wordt ondersteund om het gebruik van de verschillende Blokopslag in Azure te combineren die zijn gecertificeerd voor HANA- EN NFS-shares op basis van Azure NetApp Files. Het is bijvoorbeeld mogelijk om /hana/data in Premium Storage v1 of v2 en /hana/log te plaatsen op Ultra Disk Storage om de vereiste lage latentie te verkrijgen. Als u een volume gebruikt op basis van ANF voor /hana/data, kan /hana/log-volume ook worden geplaatst op een van de HANA-gecertificeerde Azure-blokopslagtypen. Het gebruik van NFS boven op ANF voor een van de volumes (zoals /hana/data) en Azure Premium Storage v1/v2 of Ultra Disk voor het andere volume (zoals /hana/log) wordt ondersteund.

In de on-premises wereld hoefde u zelden om de I/O-subsystemen en de mogelijkheden ervan te zorgen. Reden was dat de leverancier van het apparaat ervoor moest zorgen dat aan de minimale opslagvereisten voor SAP HANA wordt voldaan. Wanneer u de Azure-infrastructuur zelf bouwt, moet u rekening houden met een aantal van deze door SAP uitgegeven vereisten. Enkele van de minimale doorvoerkenmerken die SAP aanbeveelt, zijn:

Lezen/schrijven op /hana/logboek van 250 MB per seconde met 1 MB I/O-grootten
Leesactiviteit van ten minste 400 MB per seconde voor /hana/data voor I/O-grootten van 16 MB en 64 MB
Schrijfactiviteit van ten minste 250 MB per seconde voor /hana/data met I/O-grootten van 16 MB en 64 MB

Aangezien lage opslaglatentie essentieel is voor DBMS-systemen, zelfs als DBMS, zoals SAP HANA, gegevens in het geheugen bewaren. Het kritieke pad in de opslag bevindt zich meestal rond de schrijfbewerkingen van het transactielogboek van de DBMS-systemen. Maar ook bewerkingen zoals het schrijven van savepoints of het laden van gegevens in het geheugen na crashherstel kan essentieel zijn. Daarom is het verplicht om Azure Premium Storage v1/v2, Ultra Disk of ANF te gebruiken voor /hana/data en /hana/log-volumes .

Enkele richtlijnen voor het selecteren van uw opslagconfiguratie voor HANA kunnen worden vermeld als:

Bepaal het type opslag op basis van Azure Storage-typen voor SAP-werkbelasting en selecteer een schijftype
De totale I/O-doorvoer van vm's en IOPS-limieten in gedachten bij het bepalen of bepalen van de grootte van een VIRTUELE machine. Totale doorvoer van VM-opslag wordt beschreven in het artikel Geoptimaliseerde grootten van virtuele machines die zijn geoptimaliseerd voor geheugen
Probeer bij het bepalen van de opslagconfiguratie onder de totale doorvoer van de VIRTUELE machine te blijven met de configuratie van uw /hana-/gegevensvolume . SAP HANA voor het schrijven van savepoints, HANA kan agressief I/Os uitgeven. Het is eenvoudig mogelijk om de doorvoerlimieten van uw /hana/gegevensvolume te verhogen bij het schrijven van een savepoint. Als uw schijven die het /hana/gegevensvolume bouwen een hogere doorvoer hebben dan uw VIRTUELE machine toestaat, kunt u situaties tegenkomen waarin de doorvoer die wordt gebruikt door het schrijven van savepoint, de doorvoervereisten van de schrijfbewerkingen voor het opnieuw uitvoeren van logboeken verstoort. Een situatie die van invloed kan zijn op de doorvoer van de toepassing
Als u HANA-systeemreplicatie overweegt te gebruiken, moet de opslag die wordt gebruikt voor /hana/gegevens op elke replica hetzelfde zijn en moet het opslagtype dat wordt gebruikt voor /hana/log op elke replica hetzelfde zijn. Het gebruik van Azure Premium Storage v1 voor /hana/data met één VM en Azure Ultra Disk voor /hana/data in een andere VM waarop een replica van dezelfde HANA-systeemreplicatieconfiguratie wordt uitgevoerd, wordt bijvoorbeeld niet ondersteund

Belangrijk

De suggesties voor de opslagconfiguraties in deze of volgende documenten zijn bedoeld als aanwijzingen om mee te beginnen. Wanneer u workload uitvoert en patronen voor opslaggebruik analyseert, realiseert u zich mogelijk dat u niet alle opgegeven opslagbandbreedte of IOPS gebruikt. U kunt overwegen om de grootte van de opslag vervolgens te verkleinen. Of in tegenstelling tot uw workload heeft uw workload mogelijk meer opslagdoorvoer nodig dan bij deze configuraties wordt voorgesteld. Als gevolg hiervan moet u mogelijk meer capaciteit, IOPS of doorvoer implementeren. Op het gebied van spanning tussen de vereiste opslagcapaciteit, opslaglatentie nodig, opslagdoorvoer en IOPS vereist en minst dure configuratie, biedt Azure voldoende verschillende opslagtypen met verschillende mogelijkheden en verschillende prijspunten om het juiste compromis voor u en uw HANA-workload te vinden en aan te passen.

Stripe-sets versus SAP HANA-gegevensvolumepartitionering

Met Azure Premium Storage v1 kunt u de beste prijs-/prestatieverhouding bereiken wanneer u de /hana/data en/of /hana/log-volume over meerdere Azure-schijven stript. In plaats van grotere schijfvolumes te implementeren die meer bieden voor IOPS of doorvoer die nodig zijn. Het maken van één volume op meerdere Azure-schijven kan worden gerealiseerd met LVM- en MDADM-volumebeheerders, die deel uitmaken van Linux. De methode van stripingschijven is decennia oud en bekend. Net zo nuttig als die gestreepte volumes zijn om toegang te krijgen tot de IOPS- of doorvoermogelijkheden die u mogelijk nodig hebt, voegt het complexiteit toe bij het beheren van deze gestreepte volumes. Vooral in gevallen waarin de volumes moeten worden uitgebreid in capaciteit. Ten minste voor /hana/data heeft SAP een alternatieve methode geïntroduceerd die hetzelfde doel bereikt als het stripen van meerdere Azure-schijven. Sinds SAP HANA 2.0 SPS03, kan de HANA-indexserver de I/O-activiteit stripen over meerdere HANA-gegevensbestanden, die zich op verschillende Azure-schijven bevinden. Het voordeel is dat u niet hoeft te zorgen voor het maken en beheren van een gestreept volume op verschillende Azure-schijven. De SAP HANA-functionaliteit van partitionering van gegevensvolumes wordt gedetailleerd beschreven in:

Door de details te lezen, is het duidelijk dat het toepassen van deze functionaliteit complexiteit wegneemt van stripesets op basis van volumebeheer. U realiseert zich ook dat partitionering van HANA-gegevensvolumes niet alleen werkt voor Azure-blokopslag, zoals Azure Premium Storage v1/v2. U kunt deze functionaliteit ook gebruiken om over NFS-shares te stripen als deze shares IOPS- of doorvoerbeperkingen hebben.

Linux I/O Scheduler-modus

Linux heeft verschillende I/O-planningsmodi. Algemene aanbeveling via Linux-leveranciers en SAP is het opnieuw configureren van de I/O-plannermodus voor schijfvolumes van de mq-deadline - of kybermodus naar de noop (niet-multiqueue) of geen voor (multiqueue) modus als deze nog niet wordt uitgevoerd door de SLES saptune-profielen. Er wordt naar details verwezen in:

Laat op Red Hat de instellingen ingesteld door de specifieke tune-profielen voor de verschillende SAP-toepassingen.

Stripe-grootten bij het gebruik van logische volumebeheerders

Als u LVM of mdadm gebruikt om stripesets te bouwen op verschillende Azure Premium-schijven, moet u stripegrootten definiëren. Deze grootten verschillen tussen /hana/data en /hana/log. Aanbeveling: Aangezien stripe grootten het aanbeveling is om te gebruiken:

256 KB voor /hana/data
64 KB voor /hana/log

Notitie

De stripegrootte voor /hana/data is gewijzigd van eerdere aanbevelingen die 64 kB of 128 KB aanroepen tot 256 KB op basis van klantervaringen met recentere Linux-versies. De grootte van 256 kB biedt iets betere prestaties. We hebben ook de aanbeveling voor stripe-grootten van /hana/log gewijzigd van 32 kB in 64 kB om voldoende doorvoer te krijgen met grotere I/O-grootten.

Notitie

U hoeft geen redundantieniveau te configureren met BEHULP van RAID-volumes, omdat Azure Block Storage drie installatiekopieën van een VHD bewaart. Het gebruik van een stripeset met Azure Premium-schijven is uitsluitend bedoeld om volumes te configureren die voldoende IOPS- en/of I/O-doorvoer bieden.

Het accumuleren van meerdere Azure-schijven onder een stripeset is accumulatief van een IOPS- en opslagdoorvoerzijde. Dus als u een stripe instelt op meer dan 3 x P30 Azure Premium Storage v1-schijven, krijgt u drie keer de IOPS en drie keer de opslagdoorvoer van één Azure Premium Storage v1 P30-schijf.

Belangrijk

Als u LVM of mdadm als volumebeheer gebruikt om stripesets te maken op meerdere Azure Premium-schijven, mogen de drie SAP HANA-bestandssysteems /data, /log en /shared niet in een standaard- of hoofdvolumegroep worden geplaatst. Het wordt ten zeerste aanbevolen om de richtlijnen voor Linux-leveranciers te volgen. Dit is doorgaans het maken van afzonderlijke volumegroepen voor /data, /log en /shared.

Overwegingen voor het gedeelde HANA-bestandssysteem

Bij het aanpassen van de grootte van de HANA-bestandssystemen wordt de meeste aandacht besteed aan de HANA-systemen voor gegevens en logboekbestanden. /hana/shared speelt echter ook een belangrijke rol bij het gebruik van een stabiel HANA-systeem, omdat het essentiële onderdelen zoals de binaire HANA-bestanden host.
Als /hana/shared onderbezet kan worden als gevolg van overmatige lees-/schrijfbewerkingen, bijvoorbeeld tijdens het schrijven van een grote dump of tijdens intensieve tracering, of als back-up naar het /hana/gedeelde bestandssysteem wordt geschreven. Latentie kan ook toenemen.

Als het HANA-systeem zich in een hoge beschikbaarheidsconfiguratie bevindt, kunnen trage reacties van het gedeelde bestandssysteem, bijvoorbeeld /hana/shared , time-outs van clusterresources veroorzaken. Deze time-outs kunnen leiden tot onnodige failovers, omdat de HANA-resourceagents mogelijk ten onrechte ervan uitgaan dat de database niet beschikbaar is.

De SAP-richtlijnen voor /hana/gedeelde aanbevolen grootten zien er als volgt uit:

Volume	Aanbevolen grootte
/hana/shared scale-up	Min(1 TB, 1 x RAM)
/hana/shared scale-out	1 x RAM van werkknooppunt per vier werkknooppunten

Raadpleeg de volgende SAP-notities voor meer informatie:
3288971 - Veelgestelde vragen: SUSE HAE/RedHat HAA Pacemaker Cluster Resource Manager in SAP HANA System Replication Environments
1999930 - Veelgestelde vragen: SAP HANA I/O-analyse

Als best practice kunt u de grootte /hana/shared aanpassen om knelpunten in de prestaties te voorkomen. Houd er rekening mee dat een goed /hana/gedeeld bestandssysteem bijdraagt aan de stabiliteit en betrouwbaarheid van uw SAP HANA-systeem, met name in ha-scenario's.

Azure Premium Storage v1-configuraties voor HANA

Lees het document SAP HANA Azure Virtual Machine Premium SSD-opslagconfiguraties voor gedetailleerde aanbevelingen voor HANA-opslag met behulp van Azure Premium Storage v1.