Configuraties van SAP HANA in virtuele Azure-machineopslag
Azure biedt verschillende soorten opslag die geschikt zijn voor Azure-VM's die worden uitgevoerd SAP HANA. De SAP HANA gecertificeerde Azure-opslagtypen die kunnen worden overwogen voor SAP HANA implementaties, zoals:
- Azure Premium SSD of Premium Storage
- Ultraschijven
- Azure NetApp Files
Zie voor meer informatie over deze schijftypen het artikel Azure Storage typen voor SAP-workload en Een schijftype selecteren
Azure biedt twee implementatiemethoden voor VHD's in Azure Standard en Premium Storage. We verwachten dat u profiteert van beheerde Azure-schijven voor azure-implementaties voor blokopslag.
Zie 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 in die opslag wordt gebruikt, door SAP worden ondersteund voor het specifieke besturingssysteem en DBMS. Sap-ondersteunings opmerking #2972496 vermeldt de ondersteunde bestandssystemen voor verschillende besturingssystemen en databases, waaronder SAP HANA. Dit geldt voor alle volumes SAP HANA toegang hebben 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 verder gezegd in dit artikel
De minimale SAP HANA gecertificeerde voorwaarden voor de verschillende opslagtypen zijn:
- Azure Premium Storage - /hana/log is vereist om te worden ondersteund door Azure Write Accelerator. Het /hana/gegevensvolume kan worden geplaatst in Premium-opslag zonder Azure Write Accelerator of ultraschijf
- Azure Ultra Disk ten minste voor het volume /hana/log. Het /hana/gegevensvolume kan worden geplaatst op premium-opslag 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
Sommige opslagtypen kunnen worden gecombineerd. Het is bijvoorbeeld mogelijk om /hana/data in Premium Storage te plaatsen en /hana/log kan worden geplaatst op Ultra Disk Storage om de vereiste lage latentie te krijgen. Als u een volume op basis van ANF voor /hana/data gebruikt, moet /hana/log volume ook worden gebaseerd op NFS boven op ANF. Het gebruik van NFS boven op ANF voor een van de volumes (zoals /hana/data) en Azure Premium Storage of Ultra Disk voor het andere volume (zoals /hana/log) wordt niet ondersteund.
In de on-premises wereld hebt u zich zelden zorgen moeten maken over de I/O-subsystemen en de mogelijkheden ervan. De reden hiervoor was dat de leverancier van het apparaat ervoor moest zorgen dat aan de minimale opslagvereisten voor SAP HANA. 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 I/O-grootten van 1 MB
- Leesactiviteit van ten minste 400 MB per seconde voor /hana/data voor 16 MB en 64 MB I/O-grootten
- Schrijfactiviteit van ten minste 250 MB per seconde voor /hana/gegevens met een I/O-grootte van 16 MB en 64 MB
Gezien het feit dat lage opslaglatentie essentieel is voor DBMS-systemen, zelfs als DBMS, zoals SAP HANA, gegevens in het geheugen houden. Het kritieke pad in de opslag ligt meestal rond het transactielogboek van de DBMS-systemen. Maar ook bewerkingen zoals het schrijven van opslagpunten of het laden van gegevens in het geheugen na crashherstel kunnen essentieel zijn. Daarom is het verplicht om Azure Premium Storage, 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 voor SAP-workload en selecteer een schijftype
- De totale I/O-doorvoer en IOPS-limieten van de VM worden in gedachten bij het bepalen van de VM-grootten of bij het kiezen van een VM. De algehele doorvoer van VM-opslag wordt beschreven in het artikel Voor geheugen geoptimaliseerde VM-grootten
- Probeer bij het kiezen van de opslagconfiguratie onder de algehele doorvoer van de VM te blijven met de configuratie van uw /hana/gegevensvolume. Het schrijven van savepoints, SAP HANA kan een agressieve I/O-instantie zijn. Het is eenvoudig mogelijk om tijdens het schrijven van een savepoint de doorvoerlimieten van uw /hana/gegevensvolume op te pushen. Als uw schijven die het /hana/gegevensvolume bouwen een hogere doorvoer hebben dan uw VM toestaat, kunt u situaties krijgen waarin de doorvoer die door het schrijven van het savepoint wordt gebruikt, de doorvoer van schrijfbare redo-logboeken verstoort. Een situatie die van invloed kan zijn op de doorvoer van de toepassing
- Als u overweegt HANA-systeemreplicatie te gebruiken, moet u precies hetzelfde type Azure-opslag gebruiken voor /hana/data en /hana/log voor alle VM's die deel nemen aan de configuratie van HANA-systeemreplicatie. Het gebruik van Azure Premium Storage voor /hana/data met één VM en Azure Ultra Disk voor /hana/log in een andere VM binnen dezelfde replicatieconfiguratie van het HANA-systeem wordt bijvoorbeeld niet ondersteund
Belangrijk
De suggesties voor de opslagconfiguraties zijn bedoeld als aanwijzingen om mee te beginnen. Wanneer u workloads wilt uitvoeren en patronen voor opslaggebruik analyseert, realiseert u zich misschien dat u niet alle beschikbare opslagbandbreedte of IOPS gebruikt. U kunt dan overwegen om de opslag in te perken. Of daarentegen heeft uw workload mogelijk meer opslagdoorvoer nodig dan wordt voorgesteld met deze configuraties. Als gevolg hiervan moet u mogelijk meer capaciteit, IOPS of doorvoer implementeren. Op het gebied van de opslagcapaciteit die is vereist, de benodigde opslaglatentie, de vereiste opslagdoorvoer en de minst dure configuratie van IOPS, biedt Azure voldoende verschillende opslagtypen met verschillende mogelijkheden en verschillende prijspunten om de juiste compromissen voor u en uw HANA-workload te vinden en aan te passen.
Stripe-sets versus SAP HANA partitionering van gegevensvolumes
Met Azure Premium Storage kunt u de beste prijs-prestatieverhouding krijgen wanneer u het volume /hana/data en/of /hana/log over meerdere Azure-schijven stript. In plaats van grotere schijfvolumes te implementeren die meer over IOPS of benodigde doorvoer bieden. Tot nu toe is dit bereikt met LVM- en MLVM-volumemanagers die deel uitmaken van Linux. De methode voor het stripen van schijven is tientallen jaren oud en bekend. Net zo nuttig als deze gestreepte volumes zijn om de IOPS- of doorvoermogelijkheden te krijgen die u mogelijk nodig hebt, wordt het beheer van deze gestreepte volumes complexer. Met name in gevallen waarin de volumes uitgebreid moeten worden in capaciteit. Voor /hana/data heeft SAP ten minste een alternatieve methode geïntroduceerd waarmee hetzelfde doel wordt bereikt als striping over 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 striped volume verschillende Azure-schijven. De SAP HANA functionaliteit van partitionering van gegevensvolumes wordt uitgebreid beschreven in:
- De beheerdershandleiding voor HANA
- Blog over SAP HANA partitioneren van gegevensvolumes
- SAP-opmerking #2400005
- SAP-opmerking #2700123
Als u de details doorlezen, is het duidelijk dat het gebruik van deze functionaliteit de complexiteit van stripesets op basis van volumebeheer weg neemt. U realiseert zich ook dat de partitionering van HANA-gegevensvolumes niet alleen werkt voor Azure-blokopslag, zoals Azure Premium Storage. U kunt deze functionaliteit ook gebruiken om te stripen tussen NFS-shares voor het geval deze shares IOPS- of doorvoerbeperkingen hebben.
Linux I/O Scheduler-modus
Linux heeft verschillende I/O-planningsmodi. Veelvoorkomende aanbeveling via Linux-leveranciers en SAP is om de I/O-schedulermodus voor schijfvolumes opnieuw te configureren van de mq-deadline- of kyber-modus naar de noop -modus (niet-multiqueue) of geen voor de modus (multiqueue) als dit nog niet is gedaan door de SLES saptune-profielen. Er wordt naar details verwezen in:
Laat in Red Hat de instellingen ingesteld door de specifieke afstemmingsprofielen voor de verschillende SAP-toepassingen.
Oplossingen met Premium Storage en Azure Write Accelerator voor virtuele machines uit de Azure M-serie
Azure Write Accelerator is een functionaliteit die uitsluitend beschikbaar is voor virtuele azure-VM's uit de M-serie. Zoals de naam al zegt, is het doel van de functionaliteit het verbeteren van de I/O-latentie van schrijf schrijffunctionaliteit ten opzichte van de Azure Premium-opslag. Voor SAP HANA moet Write Accelerator alleen worden gebruikt voor het volume /hana/log. Daarom zijn /hana/data en /hana/log afzonderlijke volumes met Azure Write Accelerator ondersteuning voor het volume /hana/log.
Belangrijk
Wanneer u Azure Premium Storage gebruikt, is het gebruik van Azure Write Accelerator voor het volume /hana/log verplicht. Write Accelerator is alleen beschikbaar voor Premium-opslag en M-serie en Mv2-Series VM's. Write Accelerator werkt niet in combinatie met andere Azure VM-families, zoals Esv3 of Edsv4.
De onderstaande caching-aanbevelingen voor Azure Premium-schijven gaan uit van de I/O-kenmerken voor SAP HANA die lijst, zoals:
- Er is nauwelijks leesworkloads voor de HANA-gegevensbestanden. Uitzonderingen zijn grote I/O's na het opnieuw opstarten van het HANA-exemplaar of wanneer gegevens in HANA worden geladen. Een ander geval van grotere lees-I/O's voor gegevensbestanden kan HANA-databaseback-ups zijn. Als gevolg hiervan heeft het in de lees-caching meestal geen zin, omdat in de meeste gevallen alle gegevensbestandsvolumes volledig moeten worden gelezen.
- Schrijven op basis van de gegevensbestanden wordt ervaren in bursts op basis van HANA-savepoints en HANA-crashherstel. Het schrijven van savepoints is asynchroon en houdt geen gebruikerstransacties vast. Het schrijven van gegevens tijdens crashherstel is essentieel voor de prestaties, zodat het systeem weer snel reageert. Crashherstel moet echter tamelijk uitzonderlijke situaties zijn
- Er zijn vrijwel geen lees lezen uit de redo-bestanden van HANA. Uitzonderingen zijn grote I/O's bij het maken van back-ups van transactielogboek, crashherstel of bij het opnieuw opstarten van een HANA-exemplaar.
- De belangrijkste belasting voor de SAP HANA redo-logboekbestand is schrijf- en schrijfbestanden. Afhankelijk van de aard van de workload kunt u I/O's van slechts 4 kB of in andere gevallen een I/O-grootte van 1 MB of meer hebben. Schrijflatentie op de SAP HANA redo-logboek is essentieel voor de prestaties.
- Alle schrijf schrijft moeten op een betrouwbare manier op schijf worden opgeslagen
Aanbeveling: Als gevolg van deze waargenomen I/O-patronen door SAP HANA, moet de caching voor de verschillende volumes die gebruikmaken van Azure Premium Storage worden ingesteld als:
- /hana/data- no caching or read caching (Geen caching of lees-caching)
- /hana/log - no caching - exception for M- and Mv2-Series VMs where Azure Write Accelerator should be enabled
- /hana/shared - lezen in de caching
- Besturingssysteemschijf: wijzig de standaard caching die door Azure is ingesteld tijdens het maken van de VM niet
Als u LVM of m²m gebruikt om stripesets te bouwen op verschillende Azure Premium-schijven, moet u stripe-grootten definiëren. Deze grootten verschillen tussen /hana/data en /hana/log. Aanbeveling: Bij stripe-grootten wordt het aanbevolen om het volgende te gebruiken:
- 256 kB voor /hana/data
- 64 kB voor /hana/log
Notitie
De stripegrootte voor /hana/data is gewijzigd van eerdere aanbevelingen voor 64 kB of 128 kB in 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 met grotere I/O-grootten te krijgen.
Notitie
U hoeft geen redundantieniveau te configureren met RAID-volumes, omdat azure-blokopslag drie afbeeldingen van een VHD bewaart. Het gebruik van een stripe-set met Azure Premium-schijven is uitsluitend om volumes te configureren die voldoende IOPS en/of I/O-doorvoer bieden.
Het verzamelen van een aantal Azure-VHD's onder een stripe-set, is cumulatief van een IOPS- en opslagdoorvoerzijde. Dus als u een stripe-set op meer dan 3 X P30 Azure Premium Storage-schijven zet, moet deze u drie keer de IOPS en drie keer de opslagdoorvoer van één Azure Premium Storage P30-schijf geven.
Belangrijk
Als u LVM of msystemm als volumebeheer gebruikt om stripesets te maken op meerdere Azure Premium-schijven, mogen de drie SAP HANA FileSystems /data, /log en /shared niet in een standaard- of hoofdvolumegroep worden gezet. Het wordt ten zeerste aanbevolen om de richtlijnen van Linux-leveranciers te volgen. Dit is meestal het maken van afzonderlijke volumegroepen voor /data, /log en /shared.
Azure-burstfunctionaliteit voor Premium Storage
Voor Azure Premium Storage-schijven die kleiner zijn of gelijk zijn aan 512 GiB in capaciteit, wordt burst-functionaliteit aangeboden. De exacte manier waarop schijf bursting werkt, wordt beschreven in het artikel Schijf bursting. Wanneer u het artikel leest, begrijpt u het concept van het verhogen van IOPS en doorvoer in de tijd dat uw I/O-workload lager is dan de nominale IOPS en doorvoer van de schijven (zie Prijzen van beheerde schijven voor meer informatie over de nominale doorvoer). U gaat de delta van IOPS en doorvoer tussen uw huidige gebruik en de nominale waarden van de schijf op elkaar afwerken. De bursts zijn beperkt tot maximaal 30 minuten.
De ideale gevallen waarin deze burst-functionaliteit kan worden gepland, zijn waarschijnlijk de volumes of schijven die gegevensbestanden voor de verschillende DBMS bevatten. De I/O-workload die wordt verwacht voor deze volumes, met name bij kleine tot middelgrote systemen, ziet er naar verwachting als volgende uit:
- Lage tot gemiddelde leesworkload omdat gegevens idealiter in het cachegeheugen worden opgeslagen, of, zoals in het geval van HANA, volledig in het geheugen moeten zijn
- Bursts of write triggered by database checkpoints or savepoints that are issued on a regular base
- Back-upworkload die in een continue stroom leest in gevallen waarin back-ups niet worden uitgevoerd via momentopnamen van opslag
- Voor SAP HANA het laden van de gegevens in het geheugen nadat een exemplaar opnieuw is opgestart
Met name op kleinere DBMS-systemen waarbij uw workload slechts enkele honderden transacties per seconde verwerkt, kan een dergelijke burst-functionaliteit zinvol zijn, evenals voor de schijven of volumes waarin de transactie of het redo-logboek wordt opgeslagen. De verwachte werkbelasting voor een dergelijke schijf of volumes ziet er als volgende uit:
- Regelmatige schrijfbewerkingen naar de schijf die afhankelijk zijn van de workload en de aard van de werkbelasting, omdat elke door de toepassing uitgegeven door elke door de toepassing uitgegeven door waarschijnlijk een I/O-bewerking wordt uitgevoerd
- Hogere werkbelasting in doorvoer voor gevallen van operationele taken, zoals het maken of herbouwen van indexen
- Bursts lezen bij het uitvoeren van back-ups van transactielogboeklogboek of redo-logboeken
Aanbevolen opslagoplossing voor productie op basis van Azure Premium Storage
Belangrijk
SAP HANA certificering voor virtuele machines uit de Azure M-serie is uitsluitend met Azure Write Accelerator voor het /hana/log-volume. Als gevolg hiervan wordt verwacht dat SAP HANA implementaties op virtuele machines uit de Azure M-serie worden geconfigureerd met Azure Write Accelerator voor het /hana/log-volume.
Notitie
In scenario's waarin Azure Premium Storage is betrokken, implementeren we burst-mogelijkheden in de configuratie. Houd rekening met de manier waarop Azure Premium Disk Bursting werkt wanneer u opslagtesthulpprogramma's gebruikt, ongeacht de vorm of vorm. Bij het uitvoeren van de opslagtests die worden geleverd via het SAP HWCCT- of HCMT-hulpprogramma, verwachten we niet dat alle tests voldoen aan de criteria, omdat sommige tests het bursting-tegoed overschrijden dat u kunt verzamelen. Met name wanneer alle tests opeenvolgend zonder onderbreking worden uitgevoerd.
Notitie
Bij M32ts- en M32ls-VM's kan het gebeuren dat de schijfdoorvoer lager kan zijn dan verwacht met behulp van HCMT/HWCCT-schijftests. Zelfs bij schijf bursting of met voldoende inrichtende I/O-doorvoer van de onderliggende schijven. De hoofdoorzaak van het waargenomen gedrag is dat de HCMT/HWCCT-opslagtestbestanden volledig in de cache zijn opgeslagen in de leescache van de Premium opslaggegevensschijven. Deze cache bevindt zich op de rekenhost die de virtuele machine host en kan de testbestanden van HCMT/HWCCT volledig in de cache opslaan. In dat geval zijn de quota die worden vermeld in de kolom Maximale doorvoer in cache en tijdelijke opslag: IOPS/MBps (cachegrootte in GiB) in het artikel M-serie relevant. Met name voor M32ts en M32ls is het doorvoerquotum voor de leescache slechts 400 MB per seconde. Als gevolg van de testbestanden die volledig in de cache zijn opgeslagen, is het mogelijk dat ondanks schijf bursting of een hogere inrichtende I/O-doorvoer, de tests iets korter kunnen zijn dan de maximale doorvoer van 400 MB per seconde. Als alternatief kunt u testen zonder dat leescache is ingeschakeld op de Azure Premium opslaggegevensschijven.
Notitie
Controleer voor productiescenario's of een bepaald VM-type wordt ondersteund voor SAP HANA door SAP in de SAP-documentatie voor IAAS.
Aanbeveling: De aanbevolen configuraties met Azure Premium Storage voor productiescenario's zien er als volgende uit:
Configuratie voor SAP/hana/gegevensvolume:
| VM-SKU | RAM | Met maximaal VM I/O Doorvoer |
/hana/data | Ingerichte doorvoer | Maximale burstdoorvoer | IOPS | Burst-IOPS |
|---|---|---|---|---|---|---|---|
| M32ts | 192 GiB | 500 MBps | 4 x P6 | 200 MBps | 680 MBps | 960 | 14.000 |
| M32ls | 256 GiB | 500 MBps | 4 x P6 | 200 MBps | 680 MBps | 960 | 14.000 |
| M64ls | 512 GiB | 1000 MBps | 4 x P10 | 400 MBps | 680 MBps | 2.000 | 14.000 |
| M32dms_v2, M32ms_v2 | 875 GiB | 500 MBps | 4 x P15 | 500 MBps | 680 MBps | 4,400 | 14.000 |
| M64's, M64ds_v2, M64s_v2 | 1024 GiB | 1000 MBps | 4 x P15 | 500 MBps | 680 MBps | 4,400 | 14.000 |
| M64ms, M64dms_v2, M64ms_v2 | 1792 GiB | 1000 MBps | 4 x P20 | 600 MBps | 680 MBps | 9,200 | 14.000 |
| M128s, M128ds_v2, M128s_v2 | 2048 GiB | 2000 MBps | 4 x P20 | 600 MBps | 680 MBps | 9,200 | 14.000 |
| M192ids_v2, M192is_v2 | 2048 GiB | 2000 MBps | 4 x P20 | 600 MBps | 680 MBps | 9,200 | 14.000 |
| M128ms, M128dms_v2, M128ms_v2 | 3892 GiB | 2000 MBps | 4 x P30 | 800 MBps | geen bursting | 20.000 | geen bursting |
| M192ims, M192idms_v2 | 4096 GiB | 2000 MBps | 4 x P30 | 800 MBps | geen bursting | 20.000 | geen bursting |
| M208s_v2 | 2850 GiB | 1000 MBps | 4 x P30 | 800 MBps | geen bursting | 20.000 | geen bursting |
| M208ms_v2 | 5.700 GiB | 1000 MBps | 4 x P40 | 1000 MBps | geen bursting | 30,000 | geen bursting |
| M416s_v2 | 5.700 GiB | 2000 MBps | 4 x P40 | 1000 MBps | geen bursting | 30,000 | geen bursting |
| M416ms_v2 | 11.400 GiB | 2000 MBps | 4 x P50 | 1000 MBps | geen bursting | 30,000 | geen bursting |
Voor het volume /hana/log. de configuratie ziet er als volgende uit:
| VM-SKU | RAM | Met maximaal VM I/O Doorvoer |
/hana/logboekvolume | Ingerichte doorvoer | Maximale burstdoorvoer | IOPS | Burst IOPS |
|---|---|---|---|---|---|---|---|
| M32ts | 192 GiB | 500 MBps | 3 x P10 | 300 MBps | 510 MBps | 1500 | 10,500 |
| M32ls | 256 GiB | 500 MBps | 3 x P10 | 300 MBps | 510 MBps | 1500 | 10,500 |
| M64ls | 512 GiB | 1000 MBps | 3 x P10 | 300 MBps | 510 MBps | 1500 | 10,500 |
| M32dms_v2, M32ms_v2 | 875 GiB | 500 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M64's, M64ds_v2, M64s_v2 | 1024 GiB | 1000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M64ms, M64dms_v2, M64ms_v2 | 1792 GiB | 1000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M128s, M128ds_v2, M128s_v2 | 2048 GiB | 2000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M192ids_v2, M192is_v2 | 2048 GiB | 2000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M128ms, M128dms_v2, M128ms_v2 | 3892 GiB | 2000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M192idms_v2, M192ims_v2 | 4096 GiB | 2000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M208s_v2 | 2850 GiB | 1000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M208ms_v2 | 5700 GiB | 1000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M416s_v2 | 5700 GiB | 2000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M416ms_v2 | 11.400 GiB | 2000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
Voor de andere volumes ziet de configuratie er als volgende uit:
| VM-SKU | RAM | Met maximaal VM I/O Doorvoer |
/hana/shared | /root volume | /usr/sap |
|---|---|---|---|---|---|
| M32ts | 192 GiB | 500 MBps | 1 x P15 | 1 x P6 | 1 x P6 |
| M32ls | 256 GiB | 500 MBps | 1 x P15 | 1 x P6 | 1 x P6 |
| M64ls | 512 GiB | 1000 MBps | 1 x P20 | 1 x P6 | 1 x P6 |
| M32dms_v2, M32ms_v2 | 875 GiB | 500 MBps | 1 x P30 | 1 x P6 | 1 x P6 |
| M64's, M64ds_v2, M64s_v2 | 1024 GiB | 1000 MBps | 1 x P30 | 1 x P6 | 1 x P6 |
| M64ms, M64dms_v2, M64ms_v2 | 1792 GiB | 1000 MBps | 1 x P30 | 1 x P6 | 1 x P6 |
| M128s, M128ds_v2, M128s_v2 | 2048 GiB | 2000 MBps | 1 x P30 | 1 x P10 | 1 x P6 |
| M192ids_v2, M192is_v2 | 2048 GiB | 2000 MBps | 1 x P30 | 1 x P10 | 1 x P6 |
| M128ms, M128dms_v2, M128ms_v2 | 3892 GiB | 2000 MBps | 1 x P30 | 1 x P10 | 1 x P6 |
| M192idms_v2, M192ims_v2 | 4096 GiB | 2000 MBps | 1 x P30 | 1 x P10 | 1 x P6 |
| M208s_v2 | 2850 GiB | 1000 MBps | 1 x P30 | 1 x P10 | 1 x P6 |
| M208ms_v2 | 5700 GiB | 1000 MBps | 1 x P30 | 1 x P10 | 1 x P6 |
| M416s_v2 | 5700 GiB | 2000 MBps | 1 x P30 | 1 x P10 | 1 x P6 |
| M416ms_v2 | 11.400 GiB | 2000 MBps | 1 x P30 | 1 x P10 | 1 x P6 |
Controleer of de opslagdoorvoer voor de verschillende voorgestelde volumes voldoet aan de workload die u wilt uitvoeren. Als de workload hogere volumes vereist voor /hana/data en /hana/log, moet u het aantal Azure Premium Storage-VHD's verhogen. Als u de omvang van een volume met meer VHD's dan vermeld inneemt, wordt de IOPS- en I/O-doorvoer verhoogd binnen de limieten van het type virtuele Azure-machine.
Azure Write Accelerator werkt alleen met beheerde Azure-schijven. Daarom moeten ten minste de Azure Premium Storage-schijven die het /hana/log-volume vormen, worden geïmplementeerd als beheerde schijven. Meer gedetailleerde instructies en beperkingen van Azure Write Accelerator vindt u in het artikel Write Accelerator.
Voor de door HANA gecertificeerde VM's van de Azure Esv3-familie en de Edsv4moet u ANF gebruiken voor het volume /hana/data en/hana/log. Of u hoeft alleen azure Ultra Disk Storage te gebruiken in plaats van Azure Premium Storage voor het volume /hana/log. Als gevolg hiervan kunnen de configuraties voor het volume /hana/data in Azure Premium Storage er als volgende uitzien:
| VM-SKU | RAM | Met maximaal VM I/O Doorvoer |
/hana/data | Ingerichte doorvoer | Maximale burstdoorvoer | IOPS | Burst-IOPS |
|---|---|---|---|---|---|---|---|
| E20ds_v4 | 160 GiB | 480 MBps | 3 x P10 | 300 MBps | 510 MBps | 1500 | 10,500 |
| E32ds_v4 | 256 GiB | 768 MBps | 3 x P10 | 300 MBps | 510 MBps | 1500 | 10,500 |
| E48ds_v4 | 384 GiB | 1152 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| E64ds_v4 | 504 GiB | 1200 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| E64s_v3 | 432 GiB | 1200 MB/s | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
Voor de andere volumes, waaronder /hana/log op Ultra Disk, kan de configuratie er als volgende uitzien:
| VM-SKU | RAM | Met maximaal VM I/O Doorvoer |
/hana/logboekvolume | /hana/log I/O-doorvoer | /hana/log IOPS | /hana/shared | /root volume | /usr/sap |
|---|---|---|---|---|---|---|---|---|
| E20ds_v4 | 160 GiB | 480 MBps | 80 GB | 250 MBps | 1800 | 1 x P15 | 1 x P6 | 1 x P6 |
| E32ds_v4 | 256 GiB | 768 MBps | 128 GB | 250 MBps | 1800 | 1 x P15 | 1 x P6 | 1 x P6 |
| E48ds_v4 | 384 GiB | 1152 MBps | 192 GB | 250 MBps | 1800 | 1 x P20 | 1 x P6 | 1 x P6 |
| E64ds_v4 | 504 GiB | 1200 MBps | 256 GB | 250 MBps | 1800 | 1 x P20 | 1 x P6 | 1 x P6 |
| E64s_v3 | 432 GiB | 1200 MBps | 220 GB | 250 MBps | 1800 | 1 x P20 | 1 x P6 | 1 x P6 |
Azure Ultra Disk Storage-configuratie voor SAP HANA
Een ander Azure-opslagtype heet Azure Ultra Disk. Het grote verschil tussen Azure-opslag die tot nu toe wordt aangeboden en Ultra Disk is dat de schijfmogelijkheden niet meer zijn gebonden aan de schijfgrootte. Als klant kunt u deze mogelijkheden voor Ultra Disk definiëren:
- Grootte van een schijf van 4 GiB tot 65.536 GiB
- IOPS variëren van 100 IOPS tot 160.000 IOPS (maximum is ook afhankelijk van VM-typen)
- Storage doorvoer van 300 MB per seconde tot 2000 MB per seconde
Ultra disk biedt u de mogelijkheid om één schijf te definiëren die voldoet aan uw grootte, IOPS en schijfdoorvoerbereik. In plaats van logische volumemanagers, zoals LVM of MHOKM, boven op Azure Premium Storage te gebruiken om volumes te bouwen die voldoen aan de vereisten voor IOPS- en opslagdoorvoer. U kunt een configuratiemix tussen Ultra Disk- en Premium-opslag uitvoeren. Als gevolg hiervan kunt u het gebruik van Ultra Disk beperken tot de prestatiekritieke /hana/data- en /hana/log-volumes en de andere volumes dekken met Azure Premium Storage
Andere voordelen van Ultra Disk kunnen de betere leeslatentie zijn in vergelijking met Premium-opslag. De snellere leeslatentie kan voordelen hebben wanneer u de HANA-opstarttijden en de daaropvolgende belasting van de gegevens in het geheugen wilt verminderen. Voordelen van Ultra Disk Storage kunnen ook worden gezien wanneer HANA opslagpunten schrijft.
Notitie
Ultra disk is nog niet aanwezig in alle Azure-regio's en ondersteunt ook nog niet alle onderstaande VM-typen. Raadpleeg het artikel Welke schijftypen zijn er beschikbaar in Azure?voor gedetailleerde informatie over waar Ultra Disk beschikbaar is en welke VM-families worden ondersteund.
Productie aanbevolen opslagoplossing met pure Ultra Disk-configuratie
In deze configuratie houdt u de volumes /hana/data en /hana/log afzonderlijk. De voorgestelde waarden worden afgeleid van de KPI's die SAP moet certificeren voor VM-typen voor SAP HANA- en opslagconfiguraties, zoals aanbevolen in het whitepaper voor SAP TDI Storage.
De aanbevelingen overschrijden vaak de sap-minimumvereisten, zoals eerder in dit artikel is vermeld. De vermelde aanbevelingen zijn een compromis tussen de aanbevelingen voor de grootte van SAP en de maximale opslagdoorvoer die de verschillende VM-typen bieden.
Notitie
Azure Ultra Disk afdwingt minimaal 2 IOPS per gigabyte-capaciteit van een schijf
| VM-SKU | RAM | Met maximaal VM I/O Doorvoer |
/hana/gegevensvolume | /hana/gegevens-I/O-doorvoer | /hana/gegevens-IOPS | /hana/logboekvolume | /hana/log I/O-doorvoer | /hana/log IOPS |
|---|---|---|---|---|---|---|---|---|
| E20ds_v4 | 160 GiB | 480 MB/s | 200 GB | 400 MBps | 2500 | 80 GB | 250 MB | 1800 |
| E32ds_v4 | 256 GiB | 768 MB/s | 300 GB | 400 MBps | 2500 | 128 GB | 250 MBps | 1800 |
| E48ds_v4 | 384 GiB | 1152 MB/s | 460 GB | 400 MBps | 3000 | 192 GB | 250 MBps | 1800 |
| E64ds_v4 | 504 GiB | 1200 MB/s | 610 GB | 400 MBps | 3500 | 256 GB | 250 MBps | 1800 |
| E64s_v3 | 432 GiB | 1200 MB/s | 610 GB | 400 MBps | 3500 | 220 GB | 250 MB | 1800 |
| M32ts | 192 GiB | 500 MB/s | 250 GB | 400 MBps | 2500 | 96 GB | 250 MBps | 1800 |
| M32ls | 256 GiB | 500 MB/s | 300 GB | 400 MBps | 2500 | 256 GB | 250 MBps | 1800 |
| M64ls | 512 GiB | 1000 MB/s | 620 GB | 400 MBps | 3500 | 256 GB | 250 MBps | 1800 |
| M32dms_v2, M32ms_v2 | 875 GiB | 500 MB/s | 1200 GB | 600 MBps | 5.000 | 512 GB | 250 MBps | 2500 |
| M64's, M64ds_v2, M64s_v2 | 1024 GiB | 1000 MB/s | 1200 GB | 600 MBps | 5.000 | 512 GB | 250 MBps | 2500 |
| M64ms, M64dms_v2, M64ms_v2 | 1792 GiB | 1000 MB/s | 2100 GB | 600 MBps | 5.000 | 512 GB | 250 MBps | 2500 |
| M128s, M128ds_v2, M128s_v2 | 2048 GiB | 2000 MB/s | 2400 GB | 750 MBps | 7.000 | 512 GB | 250 MBps | 2500 |
| M192ids_v2, M192is_v2 | 2048 GiB | 2000 MB/s | 2400 GB | 750 MBps | 7.000 | 512 GB | 250 MBps | 2500 |
| M128ms, M128dms_v2, M128ms_v2 | 3892 GiB | 2000 MB/s | 4800 GB | 750 MBps | 9600 | 512 GB | 250 MBps | 2500 |
| M192idms_v2, M192ims_v2 | 4096 GiB | 2000 MB/s | 4800 GB | 750 MBps | 9600 | 512 GB | 250 MBps | 2500 |
| M208s_v2 | 2850 GiB | 1000 MB/s | 3500 GB | 750 MBps | 7.000 | 512 GB | 250 MBps | 2500 |
| M208ms_v2 | 5700 GiB | 1000 MB/s | 7200 GB | 750 MBps | 14,400 | 512 GB | 250 MBps | 2500 |
| M416s_v2 | 5.700 GiB | 2000 MB/s | 7200 GB | 1000 MBps | 14,400 | 512 GB | 400 MBps | 4000 |
| M416ms_v2 | 11.400 GiB | 2000 MB/s | 14.400 GB | 1500 MBps | 28,800 | 512 GB | 400 MBps | 4000 |
De vermelde waarden zijn bedoeld als uitgangspunt en moeten worden geëvalueerd op basis van de werkelijke eisen. Het voordeel van Azure Ultra Disk is dat de waarden voor IOPS en doorvoer kunnen worden aangepast zonder de VM af te sluiten of de werkbelasting die op het systeem wordt toegepast, te stoppen.
Notitie
Tot nu toe zijn opslagmomentopnamen met Ultra Disk Storage niet beschikbaar. Hiermee blokkeert u het gebruik van VM-momentopnamen met Azure Backup Services
NFS v4.1-volumes op Azure NetApp Files
Lees voor meer informatie over ANF voor HANA het document NFS v4.1 volumes on Azure NetApp Files for SAP HANA
Kostenbewuste oplossing met Azure Premium Storage
Tot nu toe was de Azure Premium Storage-oplossing die in dit document wordt beschreven in de sectie Oplossingen met Premium Storage en Azure Write Accelerator voor virtuele machines uit de Azure M-serie bedoeld voor SAP HANA door productie ondersteunde scenario's. Een van de kenmerken van configuraties die door productie kunnen worden ondersteund, is de scheiding van de volumes voor SAP HANA en het opnieuw aanmelden bij twee verschillende volumes. Reden voor een dergelijke scheiding is dat de workloadkenmerken van de volumes verschillen. En dat met de voorgestelde productieconfiguraties een ander type caching of zelfs verschillende typen Azure-blokopslag nodig kan zijn. Voor niet-productiescenario's gelden sommige overwegingen voor productiesystemen mogelijk niet voor meer niet-productiesystemen. Als gevolg hiervan kunnen de HANA-gegevens en het logboekvolume worden gecombineerd. Maar uiteindelijk met een aantal verantwoordelijken, zoals uiteindelijk niet voldoen aan bepaalde doorvoer- of latentie-KPI's die vereist zijn voor productiesystemen. Een ander aspect om de kosten in dergelijke omgevingen te verlagen, is het gebruik van Azure Standard - SSD storage. Houd er rekening mee dat het kiezen Standard - SSD of Standard - HDD Azure Storage van invloed is op uw enkele SLA's voor virtuele Virtual Machines.
Een goedkoper alternatief voor dergelijke configuraties kan er als volgende uitzien:
| VM-SKU | RAM | Met maximaal VM I/O Doorvoer |
/hana/data en /hana/log gestreept met LVM of MSTRIPM |
/hana/shared | /root volume | /usr/sap | opmerkingen |
|---|---|---|---|---|---|---|---|
| DS14v2 | 112 GiB | 768 MB/s | 4 x P6 | 1 x E10 | 1 x E6 | 1 x E6 | Bereikt geen opslaglatentie van minder dan 1 ms1 |
| E16v3 | 128 GiB | 384 MB/s | 4 x P6 | 1 x E10 | 1 x E6 | 1 x E6 | VM-type niet gecertificeerd door HANA Bereikt geen opslaglatentie van minder dan 1 ms1 |
| M32ts | 192 GiB | 500 MB/s | 3 x P10 | 1 x E15 | 1 x E6 | 1 x E6 | Het Write Accelerator voor gecombineerde gegevens- en logboekvolume beperkt de IOPS-snelheid tot 50002 |
| E20ds_v4 | 160 GiB | 480 MB/s | 4 x P6 | 1 x E15 | 1 x E6 | 1 x E6 | Bereikt geen opslaglatentie van minder dan 1 ms1 |
| E32v3 | 256 GiB | 768 MB/s | 4 x P10 | 1 x E15 | 1 x E6 | 1 x E6 | VM-type niet gecertificeerd door HANA Bereikt geen opslaglatentie van minder dan 1 ms1 |
| E32ds_v4 | 256 GiB | 768 MBps | 4 x P10 | 1 x E15 | 1 x E6 | 1 x E6 | Bereikt geen opslaglatentie van minder dan 1 ms1 |
| M32ls | 256 GiB | 500 MB/s | 4 x P10 | 1 x E15 | 1 x E6 | 1 x E6 | Het Write Accelerator voor gecombineerde gegevens- en logboekvolume beperkt de IOPS-snelheid tot 50002 |
| E48ds_v4 | 384 GiB | 1152 MBps | 6 x P10 | 1 x E20 | 1 x E6 | 1 x E6 | Bereikt niet minder dan 1 ms opslaglatentie1 |
| E64v3 | 432 GiB | 1200 MB/s | 6 x P10 | 1 x E20 | 1 x E6 | 1 x E6 | Bereikt niet minder dan 1 ms opslaglatentie1 |
| E64ds_v4 | 504 GiB | 1200 MB/s | 7 x P10 | 1 x E20 | 1 x E6 | 1 x E6 | Bereikt niet minder dan 1 ms opslaglatentie1 |
| M64ls | 512 GiB | 1000 MB/s | 7 x P10 | 1 x E20 | 1 x E6 | 1 x E6 | Het Write Accelerator voor gecombineerde gegevens- en logboekvolume beperkt de IOPS-snelheid tot 10.0002 |
| M32dms_v2, M32ms_v2 | 875 GiB | 500 MB/s | 6 x P15 | 1 x E30 | 1 x E6 | 1 x E6 | Het Write Accelerator voor gecombineerde gegevens- en logboekvolume beperkt de IOPS-snelheid tot 50002 |
| M64's, M64ds_v2, M64s_v2 | 1024 GiB | 1000 MB/s | 7 x P15 | 1 x E30 | 1 x E6 | 1 x E6 | Het Write Accelerator voor gecombineerde gegevens- en logboekvolume beperkt de IOPS-snelheid tot 10.0002 |
| M64ms, M64dms_v2, M64ms_v2 | 1792 GiB | 1000 MB/s | 6 x P20 | 1 x E30 | 1 x E6 | 1 x E6 | Het Write Accelerator voor gecombineerde gegevens- en logboekvolume beperkt de IOPS-snelheid tot 10.0002 |
| M128s, M128ds_v2, M128s_v2 | 2048 GiB | 2000 MB/s | 6 x P20 | 1 x E30 | 1 x E10 | 1 x E6 | Het Write Accelerator voor gecombineerde gegevens- en logboekvolume beperkt de IOPS-snelheid tot 20.0002 |
| M192ids_v2, M192is_v2 | 2048 GiB | 2000 MB/s | 6 x P20 | 1 x E30 | 1 x E10 | 1 x E6 | Het Write Accelerator voor gecombineerde gegevens- en logboekvolume beperkt de IOPS-snelheid tot 20.0002 |
| M128ms, M128dms_v2, M128ms_v2 | 3800 GiB | 2000 MB/s | 5 x P30 | 1 x E30 | 1 x E10 | 1 x E6 | Het Write Accelerator voor gecombineerde gegevens- en logboekvolume beperkt de IOPS-snelheid tot 20.0002 |
| M192idms_v2, M192ims_v2 | 4096 GiB | 2000 MB/s | 5 x P30 | 1 x E30 | 1 x E10 | 1 x E6 | Het Write Accelerator voor gecombineerde gegevens- en logboekvolume beperkt de IOPS-snelheid tot 20.0002 |
| M208s_v2 | 2850 GiB | 1000 MB/s | 4 x P30 | 1 x E30 | 1 x E10 | 1 x E6 | Het Write Accelerator voor gecombineerde gegevens- en logboekvolume beperkt de IOPS-snelheid tot 10.0002 |
| M208ms_v2 | 5700 GiB | 1000 MB/s | 4 x P40 | 1 x E30 | 1 x E10 | 1 x E6 | Het Write Accelerator voor gecombineerde gegevens- en logboekvolume beperkt de IOPS-snelheid tot 10.0002 |
| M416s_v2 | 5700 GiB | 2000 MB/s | 4 x P40 | 1 x E30 | 1 x E10 | 1 x E6 | Het Write Accelerator voor gecombineerde gegevens- en logboekvolume beperkt de IOPS-snelheid tot 20.0002 |
| M416ms_v2 | 11400 GiB | 2000 MB/s | 7 x P40 | 1 x E30 | 1 x E10 | 1 x E6 | Het Write Accelerator voor gecombineerde gegevens- en logboekvolume beperkt de IOPS-snelheid tot 20.0002 |
1 Azure Write Accelerator kunnen niet worden gebruikt met de Ev4- en Ev4-VM-families. Als gevolg van het gebruik van Azure Premium Storage is de I/O-latentie niet minder dan 1 ms
2 De VM-familie ondersteunt Azure Write Accelerator,maar het is mogelijk dat de IOPS-limiet van de schrijfversneller de IOPS-mogelijkheden van schijfconfiguraties kan beperken
In het geval van het combineren van de gegevens en het logboekvolume voor SAP HANA, mogen voor de schijven die de striped volume worden gebouwd, geen leescache of lees-/schrijfcache zijn ingeschakeld.
Er worden VM-typen vermeld die niet zijn gecertificeerd met SAP en dus niet worden vermeld in de map met de SAP HANA hardware. Feedback van klanten was dat deze niet-vermelde VM-typen zijn gebruikt voor bepaalde niet-productietaken.
Volgende stappen
Zie voor meer informatie: