NFS v4.1-volumes in Azure NetApp Files voor SAP HANA

Azure NetApp Files systeemeigen NFS-shares die kunnen worden gebruikt voor /hana/shared, /hana/data en /hana/log-volumes. Voor het gebruik van op ANF gebaseerde NFS-shares voor de volumes /hana/data en /hana/log is het gebruik van het NFS-protocol v4.1 vereist. Het NFS-protocol v3 wordt niet ondersteund voor het gebruik van /hana/data en /hana/log-volumes bij het baseren van de shares op ANF.

Belangrijke overwegingen

Wanneer u Azure NetApp Files sap Netweaver en de SAP HANA overweegt, moet u rekening houden met de volgende belangrijke overwegingen:

• De minimale capaciteitspool is 4 TiB
• De minimale volumegrootte is 100 GiB
• Azure NetApp Files en alle virtuele machines, waarbij Azure NetApp Files-volumes zijn bevestigd, moeten zich in dezelfde Azure-Virtual Network of in peered virtuele netwerken in dezelfde regio
• Het is belangrijk dat de virtuele machines voor lage latentie dicht bij de Azure NetApp-opslag worden geïmplementeerd.
• Het geselecteerde virtuele netwerk moet een subnet hebben dat is gedelegeerd Azure NetApp Files
• Zorg ervoor dat de latentie van de databaseserver naar het ANF-volume wordt gemeten en lager is dan 1 milliseconde
• De doorvoer van een Azure NetApp-volume is een functie van het volumequotum en serviceniveau, zoals beschreven in Serviceniveau voor Azure NetApp Files. Zorg ervoor dat de resulterende doorvoer voldoet aan de HANA-systeemvereisten bij het formaat van de HANA Azure NetApp-volumes. U kunt ook overwegen een handmatige QoS-capaciteitspool te gebruiken waarbij volumecapaciteit en doorvoer onafhankelijk kunnen worden geconfigureerd en geschaald (SAP HANA specifieke voorbeelden vindt u in dit document
• Probeer volumes te 'consolideren' om meer prestaties te bereiken in een groter volume. Gebruik bijvoorbeeld één volume voor /sapmnt, /usr/sap/trans, ... indien mogelijk
• Azure NetApp Files biedt exportbeleid:u kunt de toegestane clients, het toegangstype (Lezen&Schrijven, Alleen-lezen, enzovoort) bepalen.
• Azure NetApp Files functie is nog niet zonebewust. Momenteel Azure NetApp Files functie niet geïmplementeerd in alle beschikbaarheidszones in een Azure-regio. Let op de mogelijke gevolgen voor latentie in sommige Azure-regio's.
• De gebruikers-id voor sidadm en de groeps-id voor op de virtuele sapsys machines moeten overeenkomen met de configuratie in Azure NetApp Files.

De HANA-database op een Azure NetApp Files

De doorvoer van een Azure NetApp-volume is een functie van de volumegrootte en het serviceniveau, zoals beschreven in Serviceniveaus voor Azure NetApp Files.

Belangrijk om te begrijpen is de prestatierelatie van de grootte en dat er fysieke limieten zijn voor een opslag-eindpunt van de service. Elk opslag-eindpunt wordt dynamisch in het Azure NetApp Files gedelegeerd subnet bij het maken van het volume en ontvangt een IP-adres. Azure NetApp Files volumes kunnen, afhankelijk van de beschikbare capaciteit en implementatielogica, een opslag-eindpunt delen

In de onderstaande tabel ziet u dat het zinvol kan zijn om een groot Standard-volume te maken voor het opslaan van back-ups en dat het niet zinvol is om een Ultra-volume te maken dat groter is dan 12 TB, omdat de maximale capaciteit van de fysieke bandbreedte van één volume wordt overschreden.

De maximale schrijfdoorvoer voor een volume en één Linux-sessie ligt tussen 1,2 en 1,4 GB/s. Als u meer doorvoer voor /hana/data nodig hebt, kunt u SAP HANA data volume partitioning gebruiken om de I/O-activiteit te stripen tijdens het opnieuw laden van gegevens of HANA-savepoints over meerdere HANA-gegevensbestanden die zich op meerdere NFS-shares bevinden. Om de leesdoorvoer te verbeteren, kan de koppelingsoptie NFS nconnect worden gebruikt. Lees Voor meer informatie over de Azure NetApp Files linux-prestaties en nconnect, de best practices voor koppelingsopties voor Linux NFS voor Azure NetApp Files. Lees de volgende artikelen voor meer informatie over het stripen van HANA-gegevensvolumes:

• De beheerdershandleiding voor HANA
• Blog over SAP HANA: gegevensvolumes partitioneren
• SAP Note #2400005
• SAP-opmerking #2700123

^1:leesdoorvoerlimieten voor schrijf- of één sessie (voor het geval NFS-koppelingsoptie nconnect niet wordt gebruikt)

Het is belangrijk om te begrijpen dat de gegevens naar dezelfde SSD's in de back-end van de opslag worden geschreven. Het prestatiequotum van de capaciteitspool is gemaakt om de omgeving te kunnen beheren. De Storage KPI's zijn gelijk voor alle HANA-databasegrootten. In bijna alle gevallen weerspiegelt deze veronderstelling niet de realiteit en de verwachting van de klant. De grootte van HANA-systemen betekent niet noodzakelijkerwijs dat een klein systeem lage opslagdoorvoer vereist en een groot systeem hoge opslagdoorvoer vereist. Maar over het algemeen kunnen we hogere doorvoervereisten verwachten voor grotere HANA-database-exemplaren. Als gevolg van de sap-regels voor het vergroten van de schaal voor de onderliggende hardware bieden dergelijke grotere HANA-exemplaren ook meer CPU-resources en een hogere parallellisme in taken zoals het laden van gegevens nadat exemplaren opnieuw zijn opgestart. Als gevolg hiervan moeten de volumegrootten worden aangepast aan de verwachtingen en vereisten van de klant. En niet alleen aangestuurd door pure capaciteitsvereisten.

Wanneer u de infrastructuur voor SAP in Azure ontwerpt, moet u rekening houden met een aantal minimale vereisten voor opslagdoorvoer (voor de besturingssystemen) van SAP, die worden omgezet in minimale doorvoerkenmerken van:

Omdat alle drie de KPI's beschadigd zijn, moet het volume /hana/data worden aangepast aan de grotere capaciteit om te voldoen aan de minimale leesvereisten. Wanneer u handmatige QoS-capaciteitspools gebruikt, kunnen de grootte en doorvoer van de volumes onafhankelijk worden gedefinieerd. Omdat zowel capaciteit als doorvoer uit dezelfde capaciteitspool worden genomen, moeten het serviceniveau en de grootte van de pool groot genoeg zijn om de totale prestaties te leveren (zie het voorbeeld hier)

Voor HANA-systemen waarvoor geen hoge bandbreedte is vereist, kan de anf-volumedoorvoer worden verlaagd door een kleinere volumegrootte of, in het geval van handmatige QoS, de doorvoer rechtstreeks aanpassen. En als een HANA-systeem meer doorvoer vereist, kan het volume worden aangepast door de capaciteit online te vergroten of te vergroten. Er zijn geen KPI's gedefinieerd voor back-upvolumes. De doorvoer van het back-upvolume is echter essentieel voor een goed presterende omgeving. Log: en de prestaties van gegevensvolumes moeten worden ontworpen aan de verwachtingen van de klant.

Om te voldoen aan de minimale sap-doorvoervereisten voor gegevens en logboeken, en volgens de richtlijnen voor /hana/shared, zien de aanbevolen grootten er als volgt uit:

Voor alle volumes wordt NFS v4.1 sterk aanbevolen

De grootten voor de back-upvolumes zijn schattingen. Exacte vereisten moeten worden gedefinieerd op basis van workload- en bewerkingsprocessen. Voor back-ups kunt u veel volumes voor verschillende SAP HANA-exemplaren samenvoegen tot één (of twee) grotere volumes, die een lager serviceniveau van ANF kunnen hebben.

Daarom kunt u overwegen om vergelijkbare doorvoer te implementeren voor de ANF-volumes die al worden vermeld voor Ultra Disk Storage. Houd ook rekening met de grootten voor de grootten die worden vermeld voor de volumes voor de verschillende VM-SKU's, zoals al is gedaan in de Ultra Disk-tabellen.

Documentatie over het implementeren van een SAP HANA-uitschaalconfiguratie met stand-by-knooppunt met NFS v4.1-volumes die worden gehost in ANF, wordt gepubliceerd in SAP HANA scale-out met stand-by-knooppunt op Azure-VM'smet Azure NetApp Files op SUSE Linux Enterprise Server .

Beschikbaarheid

ANF-systeemupdates en -upgrades worden toegepast zonder dat dit van invloed is op de klantomgeving. De gedefinieerde SLA is 99,99%.

Volumes en IP-adressen en capaciteitspools

Met ANF is het belangrijk om te begrijpen hoe de onderliggende infrastructuur wordt gebouwd. Een capaciteitspool is slechts een constructie, die een capaciteits- en prestatiebudget en factureringseenheid biedt op basis van het serviceniveau van de capaciteitspool. Een capaciteitspool heeft geen fysieke relatie met de onderliggende infrastructuur. Wanneer u een volume op de service maakt, wordt er een opslag-eindpunt gemaakt. Er wordt één IP-adres toegewezen aan dit opslag-eindpunt om gegevenstoegang tot het volume te bieden. Als u verschillende volumes maakt, worden alle volumes verdeeld over de onderliggende bare-metalpark, gekoppeld aan dit opslag-eindpunt. ANF heeft een logica die workloads van klanten automatisch distribueert zodra de volumes of/en capaciteit van de geconfigureerde opslag een intern vooraf gedefinieerd niveau bereiken. U ziet dergelijke gevallen mogelijk omdat er automatisch een nieuw opslag-eindpunt met een nieuw IP-adres wordt gemaakt voor toegang tot de volumes. De ANF-service biedt geen klantcontrole over deze distributielogica.

Logboekvolume en logboekback-upvolume

Het 'logboekvolume'(/hana/log) wordt gebruikt om het online redo-logboek te schrijven. Er bevinden zich dus open bestanden in dit volume en het heeft geen zin om een momentopname van dit volume te maken. Online redo-logboekbestanden worden gearchiveerd of er wordt een back-up van gemaakt op het back-upvolume van het logboek zodra het online redo-logboekbestand vol is of er een back-up van het redo-logboek wordt uitgevoerd. Voor redelijke back-upprestaties vereist het back-upvolume van het logboek een goede doorvoer. Om de opslagkosten te optimaliseren, kan het zinvol zijn om het logboekback-upvolume van meerdere HANA-exemplaren te consolideren. Zodat meerdere HANA-exemplaren hetzelfde volume gebruiken en hun back-ups naar verschillende directories schrijven. Met behulp van een dergelijke consolidatie kunt u meer doorvoer krijgen met omdat u het volume iets groter moet maken.

Hetzelfde geldt voor het volume waar u volledige HANA-databaseback-ups naar schrijft.
 

Backup

Naast het streamen van back-ups en het maken van back-ups van azure-back-ups van SAP HANA-databases, zoals beschreven in het artikel Back-uphandleiding voor SAP HANA op Azure Virtual Machines,biedt Azure NetApp Files de mogelijkheid om back-ups van momentopnamen op basis van opslag uit te voeren.

SAP HANA ondersteunt:

• Storage back-up van momentopnamen voor één containersysteem met SAP HANA 1.0 SPS7 en hoger
• Storage op basis van back-up van momentopnamen voor Multi Database Container (MDC) HANA-omgevingen met één tenant met SAP HANA 2.0 SPS1 en hoger
• Storage back-up van momentopnamen voor Multi Database Container (MDC) HANA-omgevingen met meerdere tenants met SAP HANA 2.0 SPS4 en hoger

Het maken van back-ups van momentopnamen op basis van opslag is een eenvoudige procedure in vier stappen,

1. Een momentopname van een HANA-database (interne) maken: een activiteit die u of hulpprogramma's moeten uitvoeren
2. SAP HANA schrijft gegevens naar de gegevensbestand om een consistente status in de opslag te maken: HANA voert deze stap uit als gevolg van het maken van een HANA-momentopname
3. Maak een momentopname op het volume /hana/data in de opslag: een stap die u of de hulpprogramma's moeten uitvoeren. U hoeft geen momentopname uit te voeren op het volume /hana/log
4. Verwijder de momentopname van de HANA-database (interne database) en hervat de normale werking: een stap die u of de hulpprogramma's moeten uitvoeren

BACKUP DATA FOR FULL SYSTEM CREATE SNAPSHOT COMMENT 'SNAPSHOT-2019-03-18:11:00';

az netappfiles snapshot create -g mygroup --account-name myaccname --pool-name mypoolname --volume-name myvolname --name mysnapname 

BACKUP DATA FOR FULL SYSTEM CLOSE SNAPSHOT BACKUP_ID 47110815 SUCCESSFUL SNAPSHOT-2020-08-18:11:00';

Deze back-upprocedure voor momentopnamen kan op verschillende manieren worden beheerd met behulp van verschillende hulpprogramma's. Een voorbeeld is het Python-script 'ntaphana_azure.py' dat beschikbaar is op GitHub Dit is voorbeeldcode die 'as-is' wordt verstrekt zonder onderhoud https://github.com/netapp/ntaphana of ondersteuning.

Beschikbare oplossingen voor toepassings-consistente back-up op basis van opslagmomentopnamen:

• Microsoft Azure-toepassing Consistent Snapshot Tool (AzAcSnap) is een opdrachtregelprogramma dat gegevensbeveiliging voor databases van derden mogelijk maakt door alle orchestration af te handelen die nodig is om ze in een toepassings-consistente status te zetten voordat een opslagmomentopname wordt gemaakt, waarna deze in een operationele status worden teruggelijnd. AzAcSnap ondersteunt back-ups op basis van momentopnamen voor HANA Large Instance en Azure NetApp Files. Zie Wat is Azure-toepassing Hulpprogramma voor consistente momentopnamen voor meer informatie
• Voor gebruikers van Commvault-back-upproducten is Commvault IntelliSnap V.11.21 en hoger een andere optie. Deze of latere versies van Commvault bieden ondersteuning Azure NetApp Files momentopname. Het artikel Commvault IntelliSnap 11.21 biedt meer informatie.

Een back-up maken van de momentopname met behulp van Azure Blob Storage

Een back-up naar Azure Blob Storage is een rendabele en snelle methode om op ANF gebaseerde back-ups van momentopnamen van HANA-databaseopslag op te slaan. Het hulpprogramma AzCopy heeft de voorkeur om de momentopnamen op te slaan in Azure Blob Storage. Download de nieuwste versie van dit hulpprogramma en installeer deze, bijvoorbeeld in de bin-map waar het Python-script van GitHub is geïnstalleerd. Download het nieuwste AzCopy-hulpprogramma:

root # wget -O azcopy_v10.tar.gz https://aka.ms/downloadazcopy-v10-linux && tar -xf azcopy_v10.tar.gz --strip-components=1
Saving to: ‘azcopy_v10.tar.gz’

De meest geavanceerde functie is de optie SYNCHRONISEREN. Als u de optie SYNCHRONISEREN gebruikt, zorgt azcopy ervoor dat de bron- en doelmap gesynchroniseerd blijven. Het gebruik van de parameter --delete-destination is belangrijk. Zonder deze parameter worden bestanden op de doelsite niet verwijderd en neemt het ruimtegebruik aan de doelzijde toe. Maak een blok-blobcontainer in uw Azure-opslagaccount. Maak vervolgens de SAS-sleutel voor de blobcontainer en synchroniseer de map met momentopnamen naar de Azure Blob-container.

Bijvoorbeeld als een dagelijkse momentopname moet worden gesynchroniseerd met de Azure Blob-container om de gegevens te beveiligen. En alleen die ene momentopname moet worden bewaard, de onderstaande opdracht kan worden gebruikt.

root # > azcopy sync '/hana/data/SID/mnt00001/.snapshot' 'https://azacsnaptmytestblob01.blob.core.windows.net/abc?sv=2021-02-02&ss=bfqt&srt=sco&sp=rwdlacup&se=2021-02-04T08:25:26Z&st=2021-02-04T00:25:26Z&spr=https&sig=abcdefghijklmnopqrstuvwxyz' --recursive=true --delete-destination=true

Volgende stappen

Lees het artikel:

• SAP HANA hoge beschikbaarheid voor virtuele Azure-machines