SAP-workloadgegevensplatform
Het gegevensplatform verwijst naar de technologieën voor gegevensopslag die ondersteuning bieden voor een SAP-workload. SAP-workloads stellen hoge eisen aan het gegevensplatform. We geven een overzicht van aanbevolen procedures voor het optimaliseren van kosten terwijl de prestaties behouden blijven.
Kosten voor gegevens optimaliseren
Impact: Kostenoptimalisatie
We raden u aan de opslagkosten voor uw SAP-workload te optimaliseren. Opslag is een essentieel onderdeel van een SAP-workload. Opslag bevat actieve gegevens en back-upgegevens die essentieel zijn voor uw organisatie. Opslag is van invloed op de prestaties, beschikbaarheid en herstelbaarheid van een SAP-workload. Het is belangrijk om de juiste prestaties tegen de juiste kosten te hebben. Hier volgen aanbevelingen om u te helpen dit doel te bereiken.
Gebruik het opslagtype gereserveerde capaciteit. Er zijn verschillende opslagopties beschikbaar waaruit u kunt kiezen op basis van de workloadvereiste. Beheerde schijven, blobopslag en back-upopslag kunnen een SAP-workload in verschillende combinaties ondersteunen. Elk van deze opties wordt geleverd met opslagreserveringsopties die de totale kosten voor permanente gegevens verlagen.
Zie voor meer informatie:
- Gereserveerde azure-schijfcapaciteit
- Gereserveerde capaciteit voor Blob Storage
- Gereserveerde capaciteit voor Azure Backup Storage
Beleid voor levenscyclusbeheer gebruiken. Behalve gereserveerde capaciteit moet u ervoor zorgen dat de gegevensretentieperiode geschikt is voor de SAP-workload. Een BACK-up van een SAP-database kan groot zijn en kan worden toegevoegd aan de opslagkosten als deze niet zijn geoptimaliseerd. U wordt aangeraden een levenscyclusbeleid te maken dat voldoet aan de beoogde hersteltijd (RTO) en RPO (Recovery Point Objective) van uw SAP-workload. Het beleid moet worden verplaatst naar Premium-, Standard-, Koude- en Archiefopslag op basis van de leeftijds- en bedrijfsvereisten.
Gegevensbetrouwbaarheid verbeteren
Impact: betrouwbaarheid
Gegevensbetrouwbaarheid is essentieel voor het waarborgen van de continuïteit van bewerkingen. We bieden aanbevelingen voor betrouwbaarheid voor het configureren van databasebetrouwbaarheid, het maken van SAPMNT-sharebetrouwbaarheid, het gebruik van back-ups en het implementeren van een noodhersteloplossing.
Databasebetrouwbaarheid configureren
Een SAP-toepassing voedt gegevens naar meerdere bedrijfssystemen, waardoor databasetolerantie een belangrijke overweging vormt voor de workload. We raden u aan productiegegevens te repliceren voor de hoogste tolerantie. Replicatie tussen regio's is de voorkeursoplossing voor herstel na noodgevallen. Maar voor een meer betaalbare optie moet u minimaal zoneredundantie configureren. De methoden die u kiest, zijn afhankelijk van het databasebeheersysteem (DBMS) en de vereiste SLA (Business Service Level Agreement). Hieronder ziet u aanbevelingen voor de databaselaag.
Definieer RPO en RTO. Voor het maken van databasetolerantie is een plan vereist om gegevensverlies te herstellen. Een logische fout in de SAP-database, een grootschalige noodgeval of een systeemstoring kan leiden tot gegevensverlies in een SAP-workload. Uw herstelplan moet bepalen hoeveel gegevens u wilt verliezen en hoe snel u moet herstellen. De hoeveelheid gegevensverlies die u wilt verliezen, is uw RPO (Recovery Point Objective). Hoe snel u moet herstellen is uw beoogde hersteltijd (RTO). Wanneer u ontwerpt voor herstelbaarheid, moet u de gewenste en werkelijke RPO en RTO van uw SAP-toepassing begrijpen.
Gebruik synchrone replicatie voor geen gegevensverlies. In sommige scenario's is er geen tolerantie voor gegevensverlies. Het beoogde herstelpunt is 0. Als u deze RPO wilt bereiken, moet u synchrone replicatie op de databaselaag gebruiken. Met synchrone replicatie worden databasetransacties doorgevoerd in database-exemplaren in twee afzonderlijke zones of regio's. U moet de latentie tussen de twee exemplaren meten om ervoor te zorgen dat deze voldoet aan de behoeften van de werkbelasting en u kunt dit doen met het SAP-meetprogramma niping
. Een hogere netwerklatentie vertraagt de schaalbaarheid van uw workload en de fysieke afstand tussen de exemplaren zorgt voor netwerklatentie. Als gevolg hiervan heeft replicatie tussen regio's een hogere latentie dan in beschikbaarheidszones, omdat er meer afstand tussen de exemplaren is. Databasereplicatie tussen verschillende regio's moet asynchroon zijn en replicatie tussen beschikbaarheidszones moet synchroon zijn. Het is belangrijk om tolerantie en latentie in sap-workloadontwerp te verdelen.
Zie voor meer informatie:
- DBMS-implementatie voor SAP-werkbelasting in algemene virtuele Azure-machines
- Architectuur en scenario's met hoge beschikbaarheid voor SAP NetWeaver
- Netwerklatentie tussen en binnen zones
Betrouwbaarheid van SAPMNT-share maken
SAPMNT host de fysieke kernelbestanden voor SAP-toepassing en kan een single point of failure zijn. Er zijn verschillende opties beschikbaar in Azure voor het maken van redundantie en het ontwerpen van een maximaal beschikbare SAPMNT-share. We raden u aan Om Azure Premium Files of Azure NetApp Files te gebruiken voor Linux en Azure Premium Files. Voor implementaties op basis van Windows moet u Azure NetApp Files of Azure Shared Disk gebruiken.
Er zijn ook enkele toepassingsspecifieke configuraties die u moet aanpakken voor SAPMNT-betrouwbaarheid. U hebt gedeelde mappen in de omgeving (/sapmnt/SID and /usr/sap/trans
) nodig om de SAP NetWeaver-toepassingslaag te implementeren. We raden u aan maximaal beschikbare bestandssystemen te maken en ervoor te zorgen dat ze tolerant zijn. De /sapmnt/SID
mappen en /usr/sap/SID/ASCS
mappen zijn belangrijk. U moet deze bestandssystemen op NFS in Azure Files plaatsen om de maximale betrouwbaarheid te bereiken.
Zie NFS in Azure Files voor meer informatie.
Tabel 1: SAPMNT-richtlijnen voor elk besturingssysteem.
Back-ups van gegevens gebruiken
De SAP-workload moet een normale back-upoplossing implementeren. Back-ups vormen de backbone van herstel na noodgevallen en helpen de continuïteit van bewerkingen te waarborgen. We hebben een aantal aanbevelingen voor de betrouwbaarheid van back-ups.
Beginnen met Azure Backup
U wordt aangeraden Azure Backup te gebruiken als de basisstrategie voor back-ups voor een SAP-workload. Azure Backup is de systeemeigen back-upoplossing in Azure en biedt meerdere mogelijkheden om uw SAP-back-ups te stroomlijnen. Met Azure Backup willen we enkele functies aanwijzen.
Tabel 2 - Azure Backup-functies
Functie | Beschrijving |
---|---|
Compatibiliteit van systeemeigen databaseback-ups | Azure Backup biedt systeemeigen back-ups via de Backint-connector voor SAP HANA-, SQL Server- en Oracle-databases die worden gebruikt door SAP-toepassingen. Azure Backup voor SAP biedt een API met de naam Backint. Met Backint kunnen back-upoplossingen rechtstreeks back-ups maken op de databaselaag. Azure Backup biedt ook ondersteuning voor de databaseback-upmogelijkheid voor HANA - en SQL Server-databases. |
Back-up van opslag | Met de functie voor opslagback-up kunt u de back-upstrategie optimaliseren met behulp van schijfmomentopnamen van Azure Premium-opslag voor selectieve schijven. Zie de consistentie van momentopnamen voor meer informatie over toepassingsconsistente back-ups. |
Back-up van virtuele machine | Maak een back-up van Azure VM-gegevens en herstel deze via Azure Portal. Met herstel tussen regio's kunt u Virtuele Azure-machines herstellen die zich in een gekoppelde secundaire regio bevonden. |
Langetermijnretentie | Met Azure Backup kunt u SAP-back-ups jaren bewaren voor nalevings- en controlebehoeften. |
Back-upbeheer | Met Azure Backup kunt u back-ups beheren vanuit Azure Portal met een eenvoudige gebruikersinterface. |
Zie voor meer informatie:
- Documentatie over Azure Backup
- Overzicht van back-ups van SAP HANA
- Azure Backup-architectuur voor SAP HANA-back-up.
- Back-uphandleiding voor SAP HANA op virtuele Azure-machines
- Back-uphandleiding voor SAP HANA-systeemreplicatiedatabases op Azure-VM's.
- Back-uprichtlijnen voor momentopnamen van SAP HANA-database-exemplaren op Azure-VM's.
- Back-uphandleiding voor SQL Server op virtuele Azure-machines
Marketplace-back-upoplossingen zoeken
Er bestaan verschillende gecertificeerde back-upoplossingen van derden in Azure Marketplace. Deze oplossingen bieden back-upmogelijkheden van leveranciers en sap-gecertificeerde back-upmogelijkheden. Overweeg deze oplossingen boven op Azure Backup te plaatsen om aangepaste oplossingen te genereren met basisondersteuning.
Microsoft-partners bieden oplossingen die zijn geïntegreerd met Azure Storage voor werkbelastingen voor archiveren, back-ups en voor bedrijfscontinuïteit en herstel na noodgevallen (BCDR). De partneroplossingen profiteren van de schaal- en kostenvoordelen van Azure Storage. U kunt de oplossingen gebruiken om back-upproblemen op te lossen, een site voor herstel na noodgevallen te maken of ongebruikte inhoud te archiveren voor langetermijnretentie. Ze kunnen tapegebaseerde back-ups vervangen en een on-demand economische herstelsite bieden met alle nalevingsstandaarden en opslagfuncties zoals onveranderbare opslag en levenscyclusbeheer.
Momentopnamen gebruiken
Een momentopname is een punt-in-time-kopie van uw gegevens. De snelheid en betrouwbaarheid van momentopnamen kunnen helpen bij het beheren van grote databases en het beschermen van de primaire database tegen beschadiging of storing. Deze functies maken momentopnamen essentieel voor herstel na noodgevallen. We hebben een aantal opties voor het maken en opslaan van back-ups voor uw SAP-workload.
Azure Backup kan bijvoorbeeld databaseback-ups maken voor HANA en SQL Server. De back-upkluisfunctie van Azure Shared Disk kan fungeren als uw oplossing voor databaseopslag. Azure NetApp Files (ANF) kan ook een back-up maken van kritieke gegevens met behulp van momentopnamen, zoals momentopname van ANF-volumes. ANF-replicatie tussen regio's maakt gebruik van ANF-momentopnamen om gegevens van de ene regio naar de andere te repliceren.
De juiste oplossing is afhankelijk van de gewenste kosten- en beschikbaarheidsniveaus. In sommige scenario's wilt u uw SAP op Azure-gegevens mogelijk repliceren naar andere Azure-regio's voor herstel na noodgevallen. U kunt echter dezelfde mogelijkheden bereiken met Azure Storage-replicatie, zoals geografisch redundante opslag (GRS) of Azure Site Recovery.
Zie voor meer informatie:
- SAP-werkbelastingconfiguraties met Azure-beschikbaarheidszones
- SAP NetWeaver-noodherstel
- Azure Site Recovery voor SAP-workloads
- Azure Storage-redundantie
- Een back-up maken van momentopnamen van SAP HANA-databases in Azure-VM's
Een plan voor herstel na noodgevallen implementeren
We raden u aan te investeren in herstel na noodgevallen (DR) om de betrouwbaarheid van de SAP-workload te verbeteren. Herstel na noodgevallen wordt bereikt door primaire gegevens te repliceren naar een secundaire locatie. Er kunnen verschillende hulpprogramma's en methodologie worden gebruikt om het doel te bereiken. Herstel na noodgevallen is vereist wanneer de primaire locatie niet toegankelijk is vanwege technische of natuurrampen. Oplossingen voor herstel na noodgevallen kunnen zich in meerdere zones binnen regio's of in verschillende regio's bevinden op basis van uw bedrijfsvereisten, maar we raden dr in verschillende regio's aan voor betere tolerantie.
Zie voor meer informatie:
- Azure Site Recovery
- Replicatie tussen regio's van Azure NetApp Files-volumes
- Kopie van momentopnamen tussen regio's voor Azure Disk Storage
- Back-up en herstel na noodgevallen
Opslagprestaties verbeteren
Impact: Prestatie-efficiëntie
Het is belangrijk om de juiste opslagoplossingen te kiezen ter ondersteuning van de gegevensbehoeften van de SAP-workload. Met de juiste oplossing kunt u de prestaties van bestaande mogelijkheden verbeteren en nieuwe functies toevoegen. Over het algemeen moet opslag voldoen aan de IOPS-vereisten (input/output operations per seconde) en doorvoerbehoeften van de SAP-database.
Zie opslagtypen voor een SAP-workload voor meer informatie.
Gebruik opslag die ondersteuning biedt voor prestatievereisten. Microsoft ondersteunt verschillende opslagtechnologie om te voldoen aan uw prestatievereiste. Voor SAP-werkbelasting kunt u Azure Managed Disk (bijvoorbeeld Premium SSD, Premium SSD v2, Standard SSD) en Azure NetApp Files gebruiken.
Opslag configureren voor prestaties. We hebben een richtlijn voor opslagconfiguratie gepubliceerd voor SAP HANA-databases. Het omvat productiescenario's en een kostenbewuste niet-productievariant. Als u de aanbevolen opslagconfiguraties volgt, zorgt u ervoor dat de opslag alle KPI's van SAP-hardware en cloudmetingsprogramma's (HCMT) doorgeeft. Zie opslagconfiguraties voor virtuele AZURE-machines in SAP HANA voor meer informatie.
Schakel schrijfversneller in. Schrijfversneller is een mogelijkheid voor VM's uit de M-serie in Premium Storage met uitsluitend Azure Managed Disks. Het is noodzakelijk om schrijfversneller in te schakelen op de schijven die zijn gekoppeld aan het volume /hana/log. Deze configuratie vereenvoudigt de latentie van schrijfbewerkingen van sub milliseconden voor blokken van 4 kB en 16 kB. Zie Azure Write Accelerator voor meer informatie.
Kies de juiste VIRTUELE machine. Het kiezen van de juiste VM heeft gevolgen voor kosten en prestaties. Het doel is om een opslag-VM te kiezen die ondersteuning biedt voor de IOPS- en doorvoervereisten van de SAP-workload. Er zijn drie kritieke gebieden waarop u zich moet richten tijdens het selecteren van een VIRTUELE machine
Tabel 3: Rekenfuncties die van invloed zijn op de prestaties
Rekenfuncties | Beschrijving |
---|---|
Aantal vCPU's | Het aantal CPU's heeft een direct effect op de licenties in het databaseknooppunt. De meeste databases volgen een basislicentiemodel. Gebruik zo nodig het bedrag dat aan uw behoeften voldoet en pas de licentieovereenkomsten aan. |
Geheugen | Geheugen is essentieel voor de prestaties van toepassingen en uw SAP-toepassing kan hoge geheugenvereisten hebben. Over het algemeen biedt een hoger geheugen meer geheugenleesbewerkingen, minder paging en hogere vm-kosten. |
Doorvoer | Doorvoer is belangrijk voor een toepassing die wordt gehost op een van de VM's om te communiceren met buiten de VIRTUELE machine met behulp van de netwerkinterfacekaarten (NIC's). |