Delen via

Azure Storage-typen voor SAP-workload

  • Artikel

Azure heeft talloze opslagtypen die sterk verschillen in mogelijkheden, doorvoer, latentie en prijzen. Sommige opslagtypen zijn niet of beperkt bruikbaar voor SAP-scenario's. Hoewel verschillende Azure-opslagtypen geschikt of geoptimaliseerd zijn voor specifieke SAP-workloadscenario's. Met name voor SAP HANA zijn sommige Azure-opslagtypen gecertificeerd voor het gebruik met SAP HANA. In dit document doorlopen we de verschillende typen opslag en beschrijven we hun mogelijkheden en bruikbaarheid met SAP-workloads en SAP-onderdelen.

Opmerking over de eenheden die in dit artikel worden gebruikt. De leveranciers van openbare clouds hebben GiB (Gibibyte) of TiB (Tebibyte als grootte-eenheden) gebruikt in plaats van Gigabyte of Terabyte. Daarom gebruiken alle Azure-documentatie en het priseren van deze eenheden. In het hele document verwijzen we uitsluitend naar deze grootte-eenheden van MiB-, GiB- en TiB-eenheden. Mogelijk moet u plannen met MB, GB en TB. Houd dus rekening met enkele kleine verschillen in de berekeningen als u een doorvoer van 400 MiB per seconde moet aanpassen in plaats van een doorvoer van 250 MiB per seconde.

Tolerantie voor Microsoft Azure Storage

Microsoft Azure-opslag van Standard HDD, Standard SSD, Azure Premium Storage, Premium SSD v2 en Ultra Disk bewaart de basis-VHD (met besturingssysteem) en gekoppelde gegevensschijven of VHD's (virtuele harde schijf) in drie kopieën op drie verschillende opslagknooppunten. Failover naar een andere replica en seeding van een nieuwe replica als er een fout optreedt in het opslagknooppunt, is transparant. Als gevolg van deze redundantie is het niet vereist om een willekeurige opslagredundantielaag te gebruiken op meerdere Azure-schijven. Dit feit wordt lokaal redundante opslag (LRS) genoemd. LRS is standaard ingesteld voor deze typen opslag in Azure. Azure NetApp Files biedt voldoende redundantie om dezelfde SLA's (Service Level Agreements) te bereiken als andere systeemeigen Azure-opslag.

Er zijn nog verschillende redundantiemethoden, die allemaal worden beschreven in het artikel Azure Storage-replicatie die van toepassing is op een aantal van de verschillende opslagtypen die Azure te bieden heeft.

Notitie

Azure Storage gebruiken voor het opslaan van databasegegevens en het opnieuw logboekbestand, LRS is het enige ondersteunde tolerantieniveau op dit moment

Houd er ook rekening mee dat verschillende Azure-opslagtypen van invloed zijn op de SLA's voor één VM-beschikbaarheid, zoals vrijgegeven in de SLA voor virtuele machines.

Beheerde Azure-schijven

Beheerde schijven zijn een resourcetype in Azure Resource Manager dat kan worden gebruikt in plaats van VHD's die zijn opgeslagen in Azure Storage-accounts. Managed Disks worden automatisch uitgelijnd met de [beschikbaarheidsset][virtual-machines-manage-availability] van de virtuele machine waaraan ze zijn gekoppeld. Met een dergelijke uitlijning ondervindt u een verbetering van de beschikbaarheid van uw virtuele machine en de services die op de virtuele machine worden uitgevoerd. Lees het overzichtsartikel voor meer informatie.

Notitie

We vereisen dat nieuwe implementaties van VIRTUELE machines die gebruikmaken van Azure-blokopslag voor hun schijven (alle Azure-opslag behalve Azure NetApp Files en Azure Files) azure managed disks moeten gebruiken voor de basis-VHD-/besturingssysteemschijven en gegevensschijven waarin SAP-databasebestanden worden opgeslagen. Onafhankelijk van of u de VM's implementeert via een beschikbaarheidsset, in Beschikbaarheidszones of onafhankelijk van de sets en zones. Schijven die worden gebruikt voor het opslaan van back-ups, hoeven niet noodzakelijkerwijs beheerde schijven te zijn.

Opslagscenario's met SAP-workloads

Permanente opslag is nodig in sap-werkbelasting in verschillende onderdelen van de stack die u in Azure implementeert. In deze scenario's worden minimaal de volgende scenario's vermeld:

  • Persistent de basis-VHD van uw VIRTUELE machine die het besturingssysteem en andere software bevat die u op die schijf installeert. Deze schijf/VHD is de hoofdmap van uw VIRTUELE machine. Wijzigingen die erin zijn aangebracht, moeten worden behouden. Dus de volgende keer stopt en start u de VIRTUELE machine opnieuw op, alle wijzigingen die zijn aangebracht voordat ze nog bestaan. Vooral in gevallen waarin de VM door Azure wordt geïmplementeerd op een andere host dan oorspronkelijk werd uitgevoerd
  • Persistente gegevensschijven. Deze schijven zijn VHD's die u koppelt om toepassingsgegevens op te slaan. Deze toepassingsgegevens kunnen gegevens zijn en logboekbestanden/opnieuw uitvoeren van een database, back-upbestanden of software-installaties. Betekent elke schijf buiten uw basis-VHD die het besturingssysteem bevat
  • Bestandsshares of gedeelde schijven die uw globale transportmap voor NetWeaver of S/4HANA bevatten. Inhoud van deze shares wordt gebruikt door software die wordt uitgevoerd op meerdere VM's of wordt gebruikt om failoverclusterscenario's met hoge beschikbaarheid te bouwen
  • De /sapmnt-map of algemene bestandsshares voor EDI-processen (Electronic Data Interchange) of vergelijkbaar. Inhoud van deze shares wordt gebruikt door software die wordt uitgevoerd op meerdere VM's of wordt gebruikt om failoverclusterscenario's met hoge beschikbaarheid te bouwen

In de volgende secties worden de verschillende Typen Azure-opslag en hun bruikbaarheid voor de vier SAP-workloadscenario's besproken. Een algemene categorisatie van de manier waarop de verschillende Azure-opslagtypen moeten worden gebruikt, wordt beschreven in het artikel Welke schijftypen zijn beschikbaar in Azure?. De aanbevelingen voor het gebruik van de verschillende Azure-opslagtypen voor SAP-werkbelasting zullen niet heel anders zijn.

Lees de SAP-ondersteuningsnotitie 2015553 voor ondersteuningsbeperkingen voor Azure-opslagtypen voor SAP NetWeaver/toepassingslaag van S/4HANA. Lees het artikel SAP HANA virtual machine storage configurations voor SAP HANA gecertificeerde en ondersteunde Azure-opslagtypen.

In de secties waarin de verschillende Typen Azure-opslag worden beschreven, krijgt u meer achtergrondinformatie over de beperkingen en mogelijkheden met behulp van de door SAP ondersteunde opslag.

Opslagkeuzen bij het gebruik van DBMS-replicatie

Onze referentiearchitecturen voorzien in het gebruik van DBMS-functionaliteit (Database Management System), zoals SQL Server Always On, HANA System Replication, Db2 HADR of Oracle Data Guard. Als u deze technologieën gebruikt tussen twee of meerdere virtuele Azure-machines, moeten de opslagtypen die voor elk van de VM's zijn gekozen, hetzelfde zijn. Dit betekent dat de opslagconfiguratie tussen het actieve knooppunt en het replicaknooppunt in de DBMS HA-configuratie hetzelfde moet zijn.

Aanbevelingen voor opslag voor SAP-opslagscenario's

Voordat u verdergaat met de details, presenteren we de samenvatting en aanbevelingen die al aan het begin van het document staan. De details voor de specifieke typen Azure Storage volgen deze sectie van het document. Wanneer we de aanbevelingen voor opslag voor de SAP-opslagscenario's in een tabel samenvatten, ziet dit er als volgt uit:

Gebruiksscenario Standard HDD Standard SSD Premium Storage Premium SSD v2 Ultraschijven Azure NetApp Files Azure Premium Files
Besturingssysteemschijf Niet geschikt Beperkt geschikt (niet-prod) Aanbevolen Niet mogelijk Niet mogelijk Niet mogelijk Niet mogelijk
Globale transportmap Niet ondersteund Niet ondersteund Aanbevolen Aanbevolen Aanbevolen Aanbevolen Sterk aanbevolen
/sapmnt Niet geschikt Beperkt geschikt (niet-prod) Aanbevolen Aanbevolen Aanbevolen Aanbevolen Sterk aanbevolen
DBMS-gegevensvolume SAP HANA M/Mv2 VM-families Niet ondersteund Niet ondersteund Aanbevolen Aanbevolen Aanbevolen Aanbevolen Niet ondersteund
DBMS-logboekvolume SAP HANA M/Mv2 VM-families Niet ondersteund Niet ondersteund Aanbevolen1 Aanbevolen Aanbevolen Aanbevolen Niet ondersteund
DBMS-gegevensvolume SAP HANA Esv3/Edsv4 VM-families Niet ondersteund Niet ondersteund Aanbevolen Aanbevolen Aanbevolen Aanbevolen Niet ondersteund
DBMS-logboekvolume SAP HANA Esv3/Edsv4 VM-families Niet ondersteund Niet ondersteund Niet ondersteund Aanbevolen Aanbevolen Aanbevolen Niet ondersteund
Gedeeld HANA-volume Niet ondersteund Niet ondersteund Aanbevolen Aanbevolen Aanbevolen Aanbevolen Aanbevolen
DBMS-gegevensvolume niet-HANA Niet ondersteund Beperkt geschikt (niet-prod) Aanbevolen Aanbevolen Aanbevolen Alleen voor specifieke Oracle-releases in Oracle Linux, Db2 en SAP ASE op SLES/RHEL Linux Niet ondersteund
DBMS-logboekvolume niet-HANA M/Mv2 VM-families Niet ondersteund Beperkt geschikt (niet-prod) Aanbevolen1 Aanbevolen Aanbevolen Alleen voor specifieke Oracle-releases in Oracle Linux, Db2 en SAP ASE op SLES/RHEL Linux Niet ondersteund
DBMS-logboekvolumes niet-HANA-niet-M/Mv2 VM-families Niet ondersteund beperkt geschikt (niet-prod) Geschikt voor maximaal gemiddelde werkbelasting Aanbevolen Aanbevolen Alleen voor specifieke Oracle-releases in Oracle Linux, Db2 en SAP ASE op SLES/RHEL Linux Niet ondersteund

1 Met het gebruik van Azure Write Accelerator voor M/Mv2 VM-families voor logboek-/opnieuw logboekvolumes

Kenmerken die u kunt verwachten uit de lijst met verschillende opslagtypen, zoals:

Gebruiksscenario Standard HDD Standard SSD Premium Storage Premium SSD v2 Ultraschijven Azure NetApp Files Azure Premium Files
Doorvoer/IOPS SLA Nee No Ja Ja Ja Ja Ja
Leesbewerkingen voor latentie Hoog Gemiddeld tot hoog Beperkt submilliseconden submilliseconden submilliseconden  Beperkt
Schrijfbewerkingen voor latentie Hoog Gemiddeld tot hoog Laag (submilliseconden1) submilliseconden submilliseconden submilliseconden  Beperkt
HANA ondersteund Nee Nr. Ja1 Ja Ja Ja Nr.
Schijfmomentopnamen mogelijk Ja Ja Ja Ja3 Nr. 2 Ja Nr.
Toewijzing van schijven op verschillende opslagclusters bij gebruik van beschikbaarheidssets Via beheerde schijven Via beheerde schijven Via beheerde schijven Schijftype wordt niet ondersteund met VM's die zijn geïmplementeerd via beschikbaarheidssets Schijftype wordt niet ondersteund met VM's die zijn geïmplementeerd via beschikbaarheidssets Nee3 Nee
Uitgelijnd met Beschikbaarheidszones Ja Ja Ja Ja Ja Openbare preview Nee
Synchrone zonegebonden redundantie Niet voor beheerde schijven Niet voor beheerde schijven Niet ondersteund voor DBMS Nee Nee No Ja
Asynchrone zonegebonden redundantie Niet voor beheerde schijven Niet voor beheerde schijven Niet ondersteund voor DBMS Nee Nr. In preview Nee
Georedundantie Niet voor beheerde schijven Niet voor beheerde schijven Nee Nee Nr. Mogelijk Nee

1 Met het gebruik van Azure Write Accelerator voor M/Mv2 VM-families voor logboek-/opnieuw logboekvolumes

2 Het maken van verschillende Azure NetApp Files-capaciteitspools garandeert geen implementatie van capaciteitspools op verschillende opslageenheden

3 (incrementele) momentopnamen van een Premium SSD v2 of een Ultra-schijf kunnen niet direct worden gebruikt nadat ze zijn gemaakt. De achtergrondkopie moet zijn voltooid voordat u een schijf kunt maken op basis van de momentopname

Belangrijk

Bekijk de sectie Azure NetApp Files van dit document voor specifieke informatie over nabijheidsplaatsing van NFS-volumes en VM's wanneer latenties van minder dan 1 milliseconden zijn vereist.

Azure Premium Storage

Azure Premium SSD-opslag is geïntroduceerd met het doel om het volgende te bieden:

  • Lage I/O-latentie
  • SLA's voor IOPS en doorvoer
  • Minder variabiliteit in I/O-latentie

Dit type opslag is gericht op DBMS-workloads, opslagverkeer waarvoor een lage latentie van milliseconden en SLA's voor IOPS en doorvoer is vereist. Kostenbasis voor Azure Premium-opslag is niet het werkelijke gegevensvolume dat op dergelijke schijven is opgeslagen, maar de groottecategorie van een dergelijke schijf, onafhankelijk van de hoeveelheid gegevens die op de schijf is opgeslagen. U kunt ook schijven maken in Premium Storage die niet rechtstreeks worden toegewezen aan de groottecategorieën die worden weergegeven in het artikel Premium SSD. Conclusies uit dit artikel zijn:

  • De opslag is ingedeeld in bereiken. Een schijf in het bereik 513 GiB tot 1024 GiB heeft bijvoorbeeld dezelfde mogelijkheden en dezelfde maandelijkse kosten
  • De IOPS per GiB volgen geen lineaire gegevens over de groottecategorieën. Kleinere schijven onder 32 GiB hebben hogere IOPS-tarieven per GiB. Voor schijven buiten 32 GiB tot 1.024 GiB is het IOPS-tarief per GiB tussen 4 en 5 IOPS per GiB. Voor grotere schijven tot 32.767 GiB is de IOPS-snelheid per GiB lager dan 1
  • De I/O-doorvoer voor deze opslag is niet lineair met de grootte van de schijfcategorie. Voor kleinere schijven, zoals de categorie tussen 65 GiB en 128 GiB-capaciteit, is de doorvoer ongeveer 780 kB per GiB. Terwijl voor de extreme grote schijven, zoals een 32.767 GiB-schijf, de doorvoer ongeveer 28 kB per GiB is
  • De SLA's voor IOPS en doorvoer kunnen niet worden gewijzigd zonder de capaciteit van de schijf te wijzigen

De mogelijkheidsmatrix voor SAP-werkbelasting ziet er als volgt uit:

Mogelijkheid Opmerking Notities/koppelingen
Besturingssysteembasis-VHD Geschikt Alle systemen
Gegevensschijf Geschikt Alle systemen - speciaal voor SAP HANA
Sap Global Transport Directory Ja Ondersteund
SAP sapmnt Geschikt Alle systemen
Back-upopslag Geschikt Voor kortetermijnopslag van back-ups
Shares/gedeelde schijf Niet beschikbaar Heeft Azure Premium Files of derden nodig
Tolerantie LRS Er zijn geen GRS of ZRS beschikbaar voor schijven
Latentie Laag tot gemiddeld -
IOPS SLA Ja -
IOPS lineair naar capaciteit semi-lineair tussen haakjes Prijzen voor Managed Disk
Maximum aantal IOPS per schijf 20.000 afhankelijk van schijfgrootte Overweeg ook VM-limieten
SLA Doorvoer Ja -
Doorvoer lineair naar capaciteit Semi-lineair tussen haakjes Prijzen voor Managed Disk
HANA gecertificeerd Ja speciaal voor SAP HANA
Ondersteuning voor Azure Write Accelerator Nee -
Disk Bursting Ja -
Schijfmomentopnamen mogelijk Ja -
Azure Backup VM-momentopnamen mogelijk Ja -
Kosten Gemiddeld -

Azure Premium Storage voldoet niet aan DE KPI's voor SAP HANA-opslaglatentie met de algemene cachetypen die worden aangeboden met Azure Premium Storage. Als u wilt voldoen aan de KPI's voor opslaglatentie voor SAP HANA-logboekschrijfbewerkingen, moet u Azure Write Accelerator-caching gebruiken, zoals beschreven in het artikel Write Accelerator inschakelen. Azure Write Accelerator profiteert van alle andere DBMS-systemen voor het schrijven van transactielogboeken en het opnieuw uitvoeren van logboekschrijfbewerkingen. Daarom is het raadzaam om deze te gebruiken voor alle SAP DBMS-implementaties. Voor SAP HANA is het gebruik van Azure Write Accelerator voor /hana/log met Azure Premium Storage verplicht.

Samenvatting: Azure Premium Storage is een van de Azure-opslagtypen die worden aanbevolen voor SAP-werkbelasting. Deze aanbeveling is van toepassing op niet-productie- en productiesystemen. Azure Premium Storage is geschikt voor het verwerken van databaseworkloads. Het gebruik van Azure Write Accelerator verbetert de schrijflatentie voor Azure Premium-schijven aanzienlijk. Voor DBMS-systemen met een hoge IOPS- en doorvoersnelheid moet u de opslagcapaciteit echter overprovisioneren. Of u moet functionaliteit zoals Windows Opslagruimten of logische volumebeheerders in Linux gebruiken om stripesets te bouwen die u de gewenste capaciteit aan de ene kant geven. Maar ook de benodigde IOPS of doorvoer tegen de beste kostenefficiëntie.

Azure Burst-functionaliteit voor Premium Storage

Voor Azure Premium Storage-schijven die kleiner 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 de toename van IOPS en doorvoer in de tijden waarin uw I/O-workload lager is dan de nominale IOPS en doorvoer van de schijven (zie prijzen voor 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 opbouwen. 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, zal er naar verwachting uitzien als:

  • Lage tot gemiddelde leesworkload omdat gegevens idealiter in het geheugen in de cache worden opgeslagen. Of net als bij SAP HANA moet volledig in het geheugen zijn
  • Bursts van schrijfbewerkingen die worden geactiveerd door databasecontrolepunten of opslagpunten die regelmatig worden uitgegeven
  • Back-upworkload die wordt gelezen in een continue stroom in gevallen waarin back-ups niet worden uitgevoerd via opslagmomentopnamen
  • Voor SAP HANA laadt u de gegevens in het geheugen nadat een exemplaar opnieuw is opgestart

Met name op kleinere DBMS-systemen waarbij uw workload slechts enkele honderd transacties per seconde verwerkt, kan een dergelijke burst-functionaliteit zinvol zijn voor de schijven of volumes die de transactie of het opnieuw logboek opslaan. De verwachte werkbelasting voor een dergelijke schijf of volumes ziet er als volgt uit:

  • Regelmatige schrijfbewerkingen naar de schijf die afhankelijk zijn van de workload en de aard van de workload, omdat elke door de toepassing uitgegeven doorvoer waarschijnlijk een I/O-bewerking activeert
  • Hogere workload in doorvoer voor gevallen van operationele taken, zoals het maken of herbouwen van indexen
  • Bursts lezen bij het uitvoeren van back-ups van transactielogboeken of opnieuw uitvoeren

Azure Premium SSD v2

Azure Premium SSD v2-opslag is een nieuwe versie van Premium-opslag die is geïntroduceerd met het doel om het volgende te bieden:

  • I/O-latentie van submilliseconden voor kleinere I/O-grootten voor lezen en schrijven
  • SLA's voor IOPS en doorvoer
  • Capaciteit betalen met de ingerichte GB
  • Een standaardset IOPS en opslagdoorvoer per schijf opgeven
  • Geef de mogelijkheid om meer IOPS en doorvoer toe te voegen aan elke schijf en afzonderlijk te betalen voor deze extra ingerichte resources
  • SAP HANA-certificering doorgeven zonder hulp van andere functionaliteit, zoals Azure Write Accelerator of andere caches

Dit type opslag is gericht op DBMS-workloads, opslagverkeer waarvoor latentie van submilliseconden en SLA's voor IOPS en doorvoer is vereist. De Premium SSD v2-schijven worden geleverd met een standaardset van 3000 IOPS en 125 MBps-doorvoer. En de mogelijkheid om meer IOPS en doorvoer toe te voegen aan afzonderlijke schijven. De prijzen van de opslag zijn gestructureerd op een manier die het toevoegen van meer doorvoer of IOPS niet van invloed is op de prijs. Toch laten we het aan u over om te bepalen hoe uw opslagconfiguratie voor Premium SSD v2 eruit gaat zien. Lees voor een basisstart SAP HANA Azure Virtual Machine Premium SSD v2-opslagconfiguraties.

Voor de werkelijke regio's is dit nieuwe blokopslagtype beschikbaar en de werkelijke beperkingen lezen het document Premium SSD v2.

De mogelijkheidsmatrix voor SAP-werkbelasting ziet er als volgt uit:

Mogelijkheid Opmerking Notities/koppelingen
Besturingssysteembasis-VHD Niet ondersteund Geen systeem
Gegevensschijf Geschikt Alle systemen
Sap Global Transport Directory Ja Alle systemen
SAP sapmnt Geschikt Alle systemen
Back-upopslag Geschikt Voor kortetermijnopslag van back-ups
Shares/gedeelde schijf Niet beschikbaar Heeft Azure Premium Files of Azure NetApp Files nodig
Tolerantie LRS Er zijn geen GRS of ZRS beschikbaar voor schijven
Latentie submilliseconden -
IOPS SLA Ja -
IOPS lineair naar capaciteit semi-lineair Prijzen voor Managed Disk
Maximum aantal IOPS per schijf 80.000 afhankelijk van schijfgrootte Overweeg ook VM-limieten
SLA Doorvoer Ja -
Doorvoer lineair naar capaciteit Semi-lineair Prijzen voor Managed Disk
HANA gecertificeerd Ja -
Ondersteuning voor Azure Write Accelerator Nee -
Disk Bursting Nee -
Schijfmomentopnamen mogelijk Ja1 -
Azure Backup VM-momentopnamen mogelijk Ja -
Kosten Gemiddeld -

1 (incrementele) momentopnamen van een Premium SSD v2 of een Ultra-schijf kunnen niet direct worden gebruikt nadat ze zijn gemaakt. De achtergrondkopie moet zijn voltooid voordat u een schijf kunt maken op basis van de momentopname

In tegenstelling tot Azure Premium Storage voldoet Azure Premium SSD v2 aan KPI's voor SAP HANA-opslaglatentie. Als gevolg hiervan hoeft u azure Write Accelerator-caching niet te gebruiken, zoals beschreven in het artikel Write Accelerator inschakelen.

Samenvatting: Azure Premium SSD v2 is de blokopslag die past bij de beste prijs-/prestatieverhouding voor SAP-workloads. Azure Premium SSD v2 is geschikt voor het verwerken van databaseworkloads. De latentie van submilliseconden is ideaal voor opslag voor veeleisende DBMS-workloads. Hoewel het een nieuwer opslagtype is dat in november 2022 is uitgebracht. Daarom zijn er mogelijk nog enkele beperkingen die de komende maanden zullen verdwijnen.

Azure Ultra Disk

Azure-ultraschijven leveren een hoge doorvoer, hoge IOPS en een consistente schijfopslag met lage latentie voor Azure IaaS-VM's. Enkele voordelen van ultraschijven zijn de mogelijkheid om de IOPS en doorvoer van de schijf dynamisch te wijzigen, samen met uw workloads, zonder dat u uw virtuele machines (VM) opnieuw hoeft op te starten. Ultraschijven zijn geschikt voor gegevensintensieve workloads, zoals SAP DBMS-werkbelasting. Ultraschijven kunnen alleen worden gebruikt als gegevensschijven en kunnen niet worden gebruikt als basis-VHD-schijf waarin het besturingssysteem wordt opgeslagen. We raden het gebruik van Azure Premium Storage aan als op basis van een VHD-schijf.

Wanneer u een ultraschijf maakt, hebt u drie dimensies die u kunt definiëren:

  • De capaciteit van de schijf. Bereiken zijn van 4 GiB tot 65.536 GiB
  • Ingerichte IOPS voor de schijf. Verschillende maximumwaarden zijn van toepassing op de capaciteit van de schijf. Lees het artikel Ultra disk voor meer informatie
  • Ingerichte opslagbandbreedte. Verschillende maximale bandbreedte is afhankelijk van de capaciteit van de schijf. Lees het artikel Ultra disk voor meer informatie

De kosten van één schijf worden bepaald door de drie dimensies die u voor de specifieke schijven afzonderlijk kunt definiëren.

De mogelijkheidsmatrix voor SAP-werkbelasting ziet er als volgt uit:

Mogelijkheid Opmerking Notities/koppelingen
Besturingssysteembasis-VHD Werkt -
Gegevensschijf Geschikt Alle systemen
Sap Global Transport Directory Ja Ondersteund
SAP sapmnt Geschikt Alle systemen
Back-upopslag Geschikt Voor kortetermijnopslag van back-ups
Shares/gedeelde schijf Niet beschikbaar Heeft een derde partij nodig
Tolerantie LRS Er zijn geen GRS of ZRS beschikbaar voor schijven
Latentie Zeer laag -
IOPS SLA Ja -
IOPS lineair naar capaciteit Semi-lineair tussen haakjes Prijzen voor Managed Disk
Maximum aantal IOPS per schijf 1.200 tot 160.000 afhankelijk van schijfcapaciteit
SLA Doorvoer Ja -
Doorvoer lineair naar capaciteit Semi-lineair tussen haakjes Prijzen voor Managed Disk
HANA gecertificeerd Ja -
Ondersteuning voor Azure Write Accelerator Nee -
Disk Bursting Ja -
Schijfmomentopnamen mogelijk Ja1 -
Azure Backup VM-momentopnamen mogelijk Ja -
Kosten Hoger dan Premium-opslag -

1 (incrementele) momentopnamen van een Premium SSD v2 of een Ultra-schijf kunnen niet direct worden gebruikt nadat ze zijn gemaakt. De achtergrondkopie moet zijn voltooid voordat u een schijf kunt maken op basis van de momentopname

Samenvatting: Azure ultraschijven zijn een geschikte opslag met lage latentie van submilliseconden voor allerlei SOORTEN SAP-workloads. Tot nu toe kan Ultra-schijf alleen worden gebruikt in combinaties met VM's die zijn geïmplementeerd via Beschikbaarheidszones (zonegebonden implementatie). In tegenstelling tot alle andere opslag kan Ultra-schijf niet worden gebruikt voor de basis-VHD-schijf. Ultra disk is ideaal voor gevallen waarin de I/O-werkbelasting veel fluctueert en u geïmplementeerde opslagdoorvoer of IOPS wilt aanpassen aan opslagworkloadpatronen in plaats van de grootte te bepalen voor het maximale gebruik van bandbreedte en IOPS.

Azure NetApp Files

Azure NetApp Files is een systeemeigen Azure-service voor hoogwaardige bestandsopslag die is gecertificeerd voor gebruik met SAP HANA. Het biedt Volumes as a Service waarvoor u NetApp-accounts, capaciteitspools en volumes maakt. Met Azure NetApp Files selecteert u service- en prestatieniveaus en beheert u gegevensbeveiliging om krachtige, maximaal beschikbare en schaalbare bestandsshares te maken en te beheren met behulp van dezelfde protocollen en hulpprogramma's waarmee u vertrouwd bent en vertrouwt op on-premises.

De volgende typen SAP-werkbelasting worden ondersteund op Azure NetApp Files-volumes:

  • SAP DBMS-workload
  • SAPMNT-share
  • Globale transportmap

Azure NetApp Files is beschikbaar in drie serviceniveaus, elk met hun eigen doorvoer- en prijsspecificaties. Welke geschikt is voor uw implementatie, is afhankelijk van de grootte van de implementatie. Aanbevelingen voor aangepaste grootten zijn beschikbaar in SAP op Azure NetApp Files TCO Estimator.

Zie Serviceniveaus voor Azure NetApp Files voor informatie over serviceniveaus.

Volumes implementeren

Gebruik voor optimale resultaten de toepassingsvolumegroep voor SAP HANA om de volumes te implementeren. De toepassingsvolumegroep plaatst volumes op optimale locaties in de Azure-infrastructuur met behulp van affiniteits- en antiaffiniteitsregels om conflicten te verminderen en om de beste doorvoer en laagste latentie mogelijk te maken.

Notitie

Capaciteitspools zijn een basisinrichtingseenheid voor Azure NetApp Files. Capaciteitspools worden aangeboden vanaf 1 TiB in grootte; u kunt een capaciteitspool uitbreiden in stappen van 1 TiB. Capaciteitspools zijn de bovenliggende eenheid voor volumes. Zie Resourcelimieten voor Azure NetApp Files voor meer informatie over de grootte. Zie Prijzen voor Azure NetApp Files voor prijzen.

Azure NetApp Files wordt ondersteund voor verschillende SAP-workloadscenario's:

Notitie

Voor DBMS-workloads in Linux gebruikt u volumes op basis van NFS in Azure NetApp Files.

Doorvoer loskoppelen van volumegrootte

Opslag voor databasetoepassingen heeft doorgaans doorvoervereisten die niet lineair worden geschaald met de grootte van de volumes. Logboekvolumes zijn relatief klein, maar vereisen hoge doorvoerniveaus.

Met Azure NetApp Files kunt u volumedoorvoer onafhankelijk van volumegrootten toewijzen wanneer u een capaciteitspool van het type handmatige QoS gebruikt.

Hier volgt een voorbeeld:

  • Een volume voor databasebestanden vereist 500 MiB/s-doorvoer en 39 TiB-capaciteit
  • Een volume voor logboekbestanden vereist 2000 MiB/s-doorvoer en 1 TiB-capaciteit

U kunt voor dit scenario een handmatige QoS-capaciteitspool maken en de doorvoer onafhankelijk van de volumegrootten toewijzen. De totale capaciteit is 40 TiB en het totale doorvoerbudget is 2500 MiB/s. Een capaciteitspool in het Premium-serviceniveau (64 MiB/s per toegewezen TiB) voldoet aan zowel prestatie- als capaciteitsvereisten (40 MiB * 64 iB/s/TiB = 2560 MiB).

Lineaire schaalaanpassing van prestaties vereist aanzienlijke overprovisioning van het logboekvolume om de doorvoervereiste te bereiken. Als u de doorvoer van 2000 MiB/s voor het logboekvolume wilt bereiken, moet u een capaciteitspool implementeren in de Ultra-laag (128 MiB/s per toegewezen TiB) van 16 TiB, wat resulteert in een overprovisioning en daarom een verspilde capaciteit van 15 TiB.

Gebruik de Azure NetApp Files Performance Calculator om een schatting te krijgen voor uw scenario.

De mogelijkheidsmatrix voor SAP-workload in Azure NetApp Files ziet er als volgt uit:

Mogelijkheid Opmerking Notities/koppelingen
Besturingssysteembasis-VHD Beheerde schijf gebruiken -
Gegevensschijf Geschikt SAP HANA, Oracle on Oracle Linux, Db2 en SAP ASE op SLES/RHEL, MAXDB, SQL Server
Sap Global Transport Directory Ja SMB (alleen Windows) en NFS (alleen Linux)
SAP sapmnt Geschikt SMB (alleen Windows) of NFS (alleen Linux)
Back-upopslag Geschikt Momentopnamen en/of Back-up van Azure NetApp Files gebruiken; logboekback-up voor HANA kan ook worden gebruikt als back-upbestemming op basis van bestanden
Shares/gedeelde schijf Ja SMB, NFS
Tolerantie LRS en GRS GRS met replicatie tussen regio's; ZRS met replicatie tussen zones
Latentie Zeer laag Meestal minder dan 1 ms
IOPS SLA Ja -
IOPS lineair naar capaciteit Lineair met automatische QoS; onafhankelijk configureerbaar met handmatige QoS Er zijn drie serviceniveaus beschikbaar
SLA Doorvoer Ja Aanbevelingen voor het aanpassen van de grootte zijn beschikbaar in sap op de Azure NetApp Files TCO-estimator
Doorvoer lineair naar capaciteit Lineair met automatische QoS; onafhankelijk configureerbaar met handmatige QoS Er zijn drie serviceniveaus beschikbaar
HANA gecertificeerd Ja -
Schijfmomentopnamen mogelijk Ja Zie hoe momentopnamen van Azure NetApp Files werken
Toepassingsconsistente momentopname en back-upindeling Nee AzAcSnap of SnapCenter gebruiken
Kosten Hulpprogramma's voor TCO-schatting gebruiken Gebruik sap op Azure NetApp Files TCO Estimator en voer de grootte van het landschap in

Andere ingebouwde functionaliteit van Azure NetApp Files-opslag:

Belangrijk

Specifiek voor database-implementaties wilt u lage latenties realiseren voor ten minste uw nieuwe logboeken. Met name voor SAP HANA vereist SAP een latentie van minder dan 1 milliseconden voor schrijfbewerkingen van HANA-logboeken van kleinere grootten. Zie de onderstaande mogelijkheden om tot dergelijke latenties te komen.

Belangrijk

Wanneer u Azure NetApp Files-volumes implementeert, moet u rekening houden met de zone waarin de virtuele machines zijn of worden geïmplementeerd. Zorg ervoor dat u dezelfde zone selecteert. Deze functionaliteit wordt beschreven in het artikel De plaatsing van het volume van de beschikbaarheidszone beheren voor Azure NetApp Files. Toepassingsvolumegroep voor SAP HANA gebruikt dezelfde functionaliteit om de volumes in de dichtstbijzijnde nabijheid van de toepassings-VM's te implementeren.

De motivatie om dit type uitlijning van beschikbaarheidszones te hebben, is het verminderen van het risicooppervlak door de NFS-shares in dezelfde beschikbaarheidszone te hebben als de vm's van de toepassing.

  • Implementeer Azure NetApp Files-volumes voor uw SAP HANA-implementatie met behulp van de toepassingsvolumegroep voor SAP HANA. Het voordeel van de toepassingsvolumegroep is dat gegevensvolumes worden geïmplementeerd via meerdere opslageindpunten, waardoor netwerkconflicten worden verminderd en de prestaties worden verbeterd.

Samenvatting: Azure NetApp Files is een gecertificeerde opslagoplossing met lage latentie voor SAP HANA. De service biedt volumes die zijn uitgesneden uit een of meer capaciteitspools. Capaciteitspools zijn beschikbaar in drie serviceniveaus die de totale capaciteit en de toegewezen doorvoer definiëren. De volumes kunnen worden aangepast en de toegewezen doorvoer kan worden aangepast zonder serviceonderbreking om te voldoen aan veranderende vereisten en om de kosten te beheren. De service biedt functionaliteit voor het repliceren van volumes naar andere regio's of zones voor herstel na noodgevallen en bedrijfscontinuïteit.

Azure Premium Files

Azure Premium Files is een gedeelde opslag die SMB en NFS biedt voor een gemiddelde prijs en voldoende latentie om shares van de SAP-toepassingslaag te verwerken. Bovendien biedt Azure Premium Files synchrone zonegebonden replicatie van de shares met een automatisme dat, als de ene replica uitvalt, een andere replica in een andere zone kan overnemen. In tegenstelling tot Azure NetApp Files zijn er geen prestatielagen. Er is ook geen capaciteitspool nodig. Opladen is gebaseerd op de werkelijke ingerichte capaciteit van de verschillende shares. Azure Premium Files is helemaal niet getest als DBMS-opslag voor SAP-werkbelasting. Maar in plaats daarvan is het gebruiksscenario voor SAP-werkbelasting gericht op alle typen SMB- en NFS-shares, omdat ze worden gebruikt op de SAP-toepassingslaag. Azure Premium Files is ook geschikt voor het gebruik voor /hana/shared.

Notitie

Tot nu toe worden geen SAP DBMS-workloads ondersteund op gedeelde volumes op basis van Azure Premium Files.

SAP-scenario's die worden ondersteund in de Azure Premium Files-lijst, zoals:

Azure Premium Files begint met een grotere hoeveelheid IOPS met een minimale sharegrootte van 100 GB in vergelijking met Azure NetApp Files. Deze hogere staaf van IOPS kan capaciteitsoverschrijding voorkomen om bepaalde IOPS- en doorvoerwaarden te bereiken. Lees voor IOPS en opslagdoorvoer de sectie Azure-bestandsshareschaaldoelen in schaalbaarheids- en prestatiedoelen van Azure Files.

Notitie

Vanwege de gelaagde architectuur van Azure Premium Files is de latentie die toegang heeft tot metagegevens van de bestanden die zijn opgeslagen in shares aanzienlijk hoger dan met Azure NetApp Files. Deze hogere latentie kan van invloed zijn op het massaal maken en verwijderen van bestanden. Maar het kan ook een merkbare invloed hebben op de tijd die nodig is om de inhoud van grote mappen weer te geven, met honderdduizenden bestanden. De belangrijkste use case die deze hogere latentie van metagegevens beïnvloedt, is het gebruik als interfaceshare, waar klanten elke dag honderdduizenden of zelfs miljoenen bestandscreaties en massaverwijderingen kunnen tegenkomen. Daarom moet u de interfacesharescenario's zorgvuldig testen. Als u wilt bepalen of uw workload veel metagegevens bevat, controleert u de workload Metagegevens of naamruimte intensief

De mogelijkheidsmatrix voor SAP-werkbelasting ziet er als volgt uit:

Mogelijkheid Opmerking Notities/koppelingen
Besturingssysteembasis-VHD Werkt -
Gegevensschijf Niet ondersteund voor SAP-workloads -
Sap Global Transport Directory Ja SMB en NFS
SAP sapmnt Geschikt Alle systemen SMB (alleen Windows) of NFS (alleen Linux)
Back-upopslag Geschikt -
Shares/gedeelde schijf Ja SMB 3.0, NFS v4.1
Tolerantie LRS en ZRS Geen GRS beschikbaar voor Azure Premium Files
Latentie  Beperkt -
IOPS SLA Ja -
IOPS lineair naar capaciteit strikt lineair -
SLA Doorvoer Ja -
Doorvoer lineair naar capaciteit strikt lineair -
HANA gecertificeerd Nee -
Schijfmomentopnamen mogelijk Ja -
Azure Backup VM-momentopnamen mogelijk Nee -
Kosten  Beperkt -

Samenvatting: Azure Premium Files is een opslag met lage latentie waarmee u NFS- en SMB-volumes of -shares kunt implementeren. Azure Premium Files biedt een uitstekende prijs-/prestatieverhouding voor SAP-toepassingslaagshares. Het biedt ook synchrone zonegebonden replicatie voor deze shares. Tot nu toe bieden we geen ondersteuning voor dit opslagtype voor de SAP DBMS-workload. Hoewel het kan worden gebruikt voor /hana/gedeelde volumes.

Azure Standard SSD-opslag

Vergeleken met Azure Standard HDD-opslag biedt Azure Standard SSD-opslag betere beschikbaarheid, consistentie, betrouwbaarheid en latentie. Het is geoptimaliseerd voor workloads die consistente prestaties nodig hebben op lagere IOPS-niveaus. Deze opslag is de minimale opslag die wordt gebruikt voor niet-productie SAP-systemen met lage IOPS- en doorvoervereisten. De mogelijkheidsmatrix voor SAP-werkbelasting ziet er als volgt uit:

Mogelijkheid Opmerking Notities/koppelingen
Besturingssysteembasis-VHD Beperkt geschikt Niet-productiesystemen
Gegevensschijf Beperkt geschikt Sommige niet-productiesystemen met lage IOPS- en latentievereisten
Sap Global Transport Directory Nee Niet ondersteund
SAP sapmnt Beperkt geschikt Niet-productiesystemen
Back-upopslag Geschikt -
Shares/gedeelde schijf Niet beschikbaar Heeft een derde partij nodig
Tolerantie LRS, GRS Geen ZRS beschikbaar voor schijven
Latentie hoog Te hoog voor SAP Global Transport-directory of productiesystemen
IOPS SLA Nee -
Maximum aantal IOPS per schijf 500 Onafhankelijk van de grootte van de schijf
SLA Doorvoer Nee -
HANA gecertificeerd Nee -
Schijfmomentopnamen mogelijk Ja -
Azure Backup VM-momentopnamen mogelijk Ja -
Kosten  Beperkt -

Samenvatting: Azure Standard SSD-opslag is de minimale aanbeveling voor niet-productie-VM's voor basis-VHD, uiteindelijke DBMS-implementaties met relatieve latentiegevoeligheid en/of lage IOPS- en doorvoersnelheden. Dit Azure-opslagtype wordt niet meer ondersteund voor het hosten van de SAP Global Transport Directory.

Azure Standard HDD-opslag

De Azure Standard HDD-opslag was het enige opslagtype toen de Azure-infrastructuur in het jaar 2014 is gecertificeerd voor de SAP NetWeaver-workload. In het jaar 2014 waren de virtuele Azure-machines klein en laag in opslagdoorvoer. Daarom kon dit opslagtype gewoon aan de eisen voldoen. De opslag is ideaal voor niet-latentiegevoelige workloads, die u nauwelijks in de SAP-ruimte ondervindt. Met de toenemende doorvoer van Azure-VM's en de toegenomen workload die deze VM's produceren, wordt dit opslagtype niet meer meegenomen voor het gebruik met SAP-scenario's. De mogelijkheidsmatrix voor SAP-werkbelasting ziet er als volgt uit:

Mogelijkheid Opmerking Notities/koppelingen
Besturingssysteembasis-VHD Niet geschikt -
Gegevensschijf Niet geschikt -
Sap Global Transport Directory Nee Niet ondersteund
SAP sapmnt NO Niet ondersteund
Back-upopslag Geschikt -
Shares/gedeelde schijf Niet beschikbaar Heeft Azure Files of derden nodig
Tolerantie LRS, GRS Geen ZRS beschikbaar voor schijven
Latentie hoog Te hoog voor DBMS-gebruik, SAP Global Transport-directory of sapmnt/saploc
IOPS SLA Nee -
Maximum aantal IOPS per schijf 500 Onafhankelijk van de grootte van de schijf
SLA Doorvoer Nee -
HANA gecertificeerd Nee -
Schijfmomentopnamen mogelijk Ja -
Azure Backup VM-momentopnamen mogelijk Ja -
Kosten Beperkt -

Samenvatting: Standard HDD is een Azure-opslagtype dat alleen moet worden gebruikt voor het opslaan van SAP-back-ups. Deze mag alleen worden gebruikt als basis-VHD voor eerder inactieve systemen, zoals buiten gebruik gestelde systemen die worden gebruikt voor het opzoeken van gegevens hier en daar. Maar er moeten geen actieve ontwikkel-, QA- of productie-VM's worden gebaseerd op die opslag. Databasebestanden die op die opslag worden gehost, mogen niet worden gehost

Limieten voor Azure-VM's in opslagverkeer

In tegenstelling tot on-premises scenario's speelt het afzonderlijke VM-type dat u selecteert een belangrijke rol in de opslagbandbreedte die u kunt bereiken. Voor de verschillende opslagtypen moet u rekening houden met:

Opslagtype Linux Windows Opmerkingen
Standard HDD Grootten voor Virtuele Linux-machines in Azure Grootten voor Virtuele Windows-machines in Azure Waarschijnlijk moeilijk om de opslaglimieten van middelgrote of grote VM's aan te raken
Standard SSD Grootten voor Virtuele Linux-machines in Azure Grootten voor Virtuele Windows-machines in Azure Waarschijnlijk moeilijk om de opslaglimieten van middelgrote of grote VM's aan te raken
Premium Storage Grootten voor Virtuele Linux-machines in Azure Grootten voor Virtuele Windows-machines in Azure Eenvoudig te bereiken IOPS of VM-limieten voor opslagdoorvoer met opslagconfiguratie
Premium SSD v2 Grootten voor Virtuele Linux-machines in Azure Grootten voor Virtuele Windows-machines in Azure Eenvoudig te bereiken IOPS of VM-limieten voor opslagdoorvoer met opslagconfiguratie
Ultraschijfopslag Grootten voor Virtuele Linux-machines in Azure Grootten voor Virtuele Windows-machines in Azure Eenvoudig te bereiken IOPS of VM-limieten voor opslagdoorvoer met opslagconfiguratie
Azure NetApp Files Grootten voor Virtuele Linux-machines in Azure Grootten voor Virtuele Windows-machines in Azure Opslagverkeer maakt gebruik van bandbreedte voor netwerkdoorvoer en geen opslagbandbreedte.
Azure Premium Files Grootten voor Virtuele Linux-machines in Azure Grootten voor Virtuele Windows-machines in Azure Opslagverkeer maakt gebruik van bandbreedte voor netwerkdoorvoer en geen opslagbandbreedte.

Als beperkingen moet u er rekening mee houden dat:

  • Hoe kleiner de virtuele machine, hoe minder schijven u kunt koppelen. Deze beperking is niet van toepassing op Azure NetApp Files. Omdat u NFS- of SMB-shares koppelt, is er geen limiet van het aantal gedeelde volumes dat moet worden gekoppeld
  • VM's hebben I/O-doorvoer- en IOPS-limieten die eenvoudig kunnen worden overschreden met Premium Storage-schijven en Ultra-schijven
  • Met Azure NetApp Files en Azure Premium Files verbruikt het verkeer naar de gedeelde volumes de netwerkbandbreedte van de VIRTUELE machine en niet de opslagbandbreedte
  • Met grote NFS-volumes in de ruimte met twee cijfers tiB-capaciteit gaat de doorvoer die toegang heeft tot een dergelijk volume van één VIRTUELE machine naar plateaus op basis van de limieten van Linux voor één sessie die communiceert met het gedeelde volume.

Wanneer u azure-VM's in de levenscyclus van een SAP-systeem omhoog instelt, moet u de IOPS- en opslagdoorvoerlimieten van het nieuwe en grotere VM-type evalueren. In sommige gevallen kan het ook zinvol zijn om de opslagconfiguratie aan te passen aan de nieuwe mogelijkheden van de Azure-VM.

Stripen of niet stripen

Door een stripeset van meerdere Azure-schijven in één groter volume te maken, kunt u de IOPS en doorvoer van de afzonderlijke schijven in één volume verzamelen. Deze wordt alleen gebruikt voor Azure Standard Storage en Azure Premium Storage. Azure Ultra Disk waar u de doorvoer en IOPS onafhankelijk van de capaciteit van een schijf kunt configureren, vereist geen gebruik van stripesets. Gedeelde volumes op basis van NFS of SMB kunnen niet worden gestreept. Vanwege de niet-lineaire aard van Azure Premium Storage-doorvoer en IOPS kunt u kleinere capaciteit inrichten met dezelfde IOPS en doorvoer dan grote Azure Premium Storage-schijven. Dit is de methode om hogere doorvoer of IOPS tegen lagere kosten te bereiken met behulp van Azure Premium Storage. Als u bijvoorbeeld over twee P15 Premium-opslagschijven stript, krijgt u een doorvoer van:

  • 250 MiB per seconde. Zo'n volume heeft 512 GiB-capaciteit. Als u één schijf wilt hebben die u 250 MiB-doorvoer per seconde geeft, moet u een P40-schijf met 2 TiB-capaciteit kiezen.
  • 400 MiB per seconde door vier P10 Premium-opslagschijven te stripen met een totale capaciteit van 512 GiB door striping. Als u één schijf met minimaal 500 MiB-doorvoer per seconde wilt hebben, moet u een P60 Premium-opslagschijf met 8 TiB kiezen. Omdat de kosten van Premium-opslag bijna lineair zijn met de capaciteit, kunt u de kostenbesparingen begrijpen door striping te gebruiken.

Sommige regels moeten worden gevolgd bij striping:

  • Er moet geen in-VM geconfigureerde opslagredundantie worden gebruikt omdat Azure Storage de gegevensschijf redundant houdt op de Back-end van Azure Storage
  • De schijven waarop de stripe-set wordt toegepast, moeten van dezelfde grootte zijn
  • Met Premium SSD v2 en Ultra Disk moet de capaciteit, ingerichte IOPS en ingerichte doorvoer hetzelfde zijn

Striping over meerdere kleinere schijven is de beste manier om een goede prijs-/prestatieverhouding te bereiken met behulp van Azure Premium Storage. Het is duidelijk dat striping extra implementatie- en beheeroverhead kan hebben.

Lees de documentatie voor de verschillende DBMS voor specifieke aanbevelingen voor stripegrootten, zoals SAP HANA Azure-configuraties voor opslag van virtuele machines.

Volgende stappen

Lees de artikelen: