Overwegingen voor azure Virtual Machines DBMS-implementatie voor SAP-workload

Deze handleiding maakt deel uit van de documentatie over het implementeren en implementeren van SAP-software op Microsoft Azure. Lees voordat u deze handleiding leest de plannings- en implementatiehandleiding en artikelen waar de planningshandleiding naar wijst. Dit document bevat informatie over de algemene implementatieaspecten van SAP-gerelateerde DBMS-systemen op Microsoft Azure virtuele machines (VM's) met behulp van de IaaS-mogelijkheden (Infrastructure as a Service) van Azure.

Het document vormt een aanvulling op de SAP-installatiedocumentatie en SAP Notes, die de primaire resources vertegenwoordigen voor installaties en implementaties van SAP-software op bepaalde platforms.

In dit document worden overwegingen geïntroduceerd voor het uitvoeren van SAP-gerelateerde DBMS-systemen in Azure-VM's. Dit hoofdstuk bevat enkele verwijzingen naar specifieke DBMS-systemen. In plaats daarvan worden de specifieke DBMS-systemen verwerkt in dit document, na dit document.

Definities

In het hele document worden deze termen gebruikt:

• IaaS: Infrastructuur als een dienst.

• PaaS: Platform as a Service.

• SaaS: Software as a Service.

• SAP-onderdeel: een afzonderlijke SAP-toepassing, zoals ERP Central Component (ECC), Business Warehouse (BW), Solution Manager of Enterprise Portal (EP). SAP-onderdelen kunnen worden gebaseerd op traditionele ABAP of Java-technologieën of op een niet-NetWeaver-toepassing zoals bedrijfsobjecten.

• SAP-omgeving: een of meer SAP-onderdelen die logisch zijn gegroepeerd om een bedrijfsfunctie uit te voeren, zoals ontwikkeling, kwaliteitscontrole, training, herstel na noodherstel of productie.

• SAP-landschap: deze term verwijst naar de volledige SAP-assets in het IT-landschap van een klant. Het SAP-landschap omvat alle productie- en niet-productieomgevingen.

• SAP-systeem: de combinatie van een DBMS-laag en een toepassingslaag van bijvoorbeeld een SAP ERP-ontwikkelsysteem, een SAP Business Warehouse-testsysteem of een SAP CRM-productiesysteem. In Azure-implementaties wordt het delen van deze twee lagen tussen on-premises en Azure niet ondersteund. Als gevolg hiervan wordt een SAP-systeem on-premises geïmplementeerd of geïmplementeerd in Azure. U kunt de verschillende systemen van een SAP-landschap implementeren in Azure of on-premises. U kunt bijvoorbeeld de SAP CRM-ontwikkel- en testsystemen implementeren in Azure, maar het SAP CRM-productiesysteem on-premises implementeren.

• Cross-premises: beschrijft een scenario waarin VM's worden geïmplementeerd in een Azure-abonnement met site-naar-site-, multisite- of Azure ExpressRoute-connectiviteit tussen de on-premises datacenters en Azure. In algemene Azure-documentatie worden dit soort implementaties ook beschreven als cross-premises scenario's.

  De reden voor de verbinding is om on-premises domeinen, on-premises Active Directory en on-premises DNS uit te breiden naar Azure. Het on-premises landschap wordt uitgebreid naar de Azure-assets van het abonnement. Met deze extensie kunnen de VM's deel uitmaken van het on-premises domein. Domeingebruikers van het on-premises domein hebben toegang tot de servers en kunnen services uitvoeren op deze VM's, zoals DBMS-services. Communicatie en naamom oplossing tussen VM's die on-premises zijn geïmplementeerd en VM's die in Azure zijn geïmplementeerd, is mogelijk. Dit scenario is het meest voorkomende scenario dat wordt gebruikt voor het implementeren van SAP-assets in Azure. Zie Planning and design for VPN gateway (Plannen en ontwerpen voor VPN-gateway) voor meer informatie.

In sommige Microsoft-documentatie worden cross-premises scenario's iets anders beschreven, met name voor DBMS-configuraties met hoge beschikbaarheid. In het geval van de SAP-gerelateerde documenten is het cross-premises scenario afhankelijk van site-naar-site- of persoonlijke ExpressRoute-connectiviteit en een SAP-landschap dat wordt gedistribueerd tussen on-premises en Azure.

Resources

Er zijn andere artikelen beschikbaar over SAP-workload in Azure. Beginnen met SAP-workload in Azure: Ga aan de slag en kies vervolgens uw interessegebied.

De volgende SAP-opmerkingen hebben betrekking op SAP on Azure betrekking tot het gebied dat in dit document wordt behandeld.

Zie de SAP-community-wikivoor meer informatie over alle SAP-notities voor Linux.

U hebt een werkende kennis nodig van Microsoft Azure architectuur en hoe Microsoft Azure virtuele machines worden geïmplementeerd en uitgevoerd. Zie Azure-documentatie voor meer informatie.

Over het algemeen zijn de Windows, Linux en DBMS-installatie en -configuratie in wezen hetzelfde als elke virtuele machine of bare-metalmachine die u on-premises installeert. Er zijn enkele beslissingen voor de implementatie van architectuur- en systeembeheer die verschillen wanneer u Azure IaaS gebruikt. In dit document worden de specifieke verschillen in architectuur- en systeembeheer uitgelegd waarop u moet worden voorbereid wanneer u Azure IaaS gebruikt.

Storage van een VM voor RDBMS-implementaties

Als u dit hoofdstuk wilt volgen, moet u de informatie in lezen en begrijpen:

• Azure Virtual Machines en implementatie voor SAP NetWeaver
• Azure Storage-typen voor SAP-workload
• Welke SAP-software wordt ondersteund voor Azure-implementaties
• SAP-workload in scenario's met virtuele Azure-machines

Voordat u dit hoofdstuk leest, moet u de verschillende VM-Series en de verschillen tussen Standard- en Premium-opslag begrijpen en weten.

Voor Blokopslag in Azure wordt het gebruik van beheerde Azure-schijven sterk aanbevolen. Lees het artikel Introduction to managed disks for Azure VMs (Inleiding tot beheerde schijven voor Azure-VM's) voor meer informatie over beheerde Azure-schijven.

In een basisconfiguratie raden we meestal een implementatiestructuur aan waarbij het besturingssysteem, DBMS en uiteindelijke SAP binaire bestanden gescheiden zijn van de databasebestanden. Als u eerdere aanbevelingen hebt veranderd, raden we u aan om afzonderlijke Azure-schijven te gebruiken voor:

• Het besturingssysteem (basis-VHD of os-VHD)
• Uitvoerbare databasebeheersysteembestanden
• Uitvoerbare SAP-bestanden zoals /usr/sap

Een configuratie die deze onderdelen in drie verschillende Azure-schijven van elkaar scheidt, kan leiden tot een hogere tolerantie omdat overmatige logboek- of dump-schrijf schrijfbare bestanden door de DBMS- of SAP-uitvoerbare bestanden de schijfquota van de besturingssysteemschijf niet verstoren.

De DBMS-gegevens en transactie-/redo-logboekbestanden worden opgeslagen in door Azure ondersteunde blokopslag of Azure NetApp Files. Ze worden opgeslagen op afzonderlijke schijven en als logische schijven gekoppeld aan de oorspronkelijke VM met de installatiesturingssysteeminstallatie van Azure. Voor Linux-implementaties worden verschillende aanbevelingen beschreven, met name voor SAP HANA. Lees het artikel Azure Storage typen voor SAP-workload voor de mogelijkheden en ondersteuning van de verschillende opslagtypen voor uw scenario.

Wanneer u de schijfindeling plant, moet u de beste balans vinden tussen deze items:

• Het aantal gegevensbestanden.
• Het aantal schijven dat de bestanden bevat.
• De IOPS-quota van één schijf of NFS-share.
• De gegevensdoorvoer per schijf of NFS-share.
• Het aantal extra gegevensschijven dat mogelijk is per VM-grootte.
• De algehele opslag- of netwerkdoorvoer die een VM kan bieden.
• De latentie die verschillende Azure Storage kunnen bieden.
• SLA's voor VM's.

Azure dwingt een IOPS-quotum af per gegevensschijf of NFS-share. Deze quota verschillen voor schijven die worden gehost op de verschillende Azure-oplossingen of -shares voor blokopslag. I/O-latentie verschilt ook tussen deze verschillende opslagtypen.

Elk van de verschillende VM-typen heeft een beperkt aantal gegevensschijven dat u kunt koppelen. Een andere beperking is dat alleen bepaalde VM-typen premium-opslag kunnen gebruiken. Normaal gesproken besluit u een bepaald type VM te gebruiken op basis van cpu- en geheugenvereisten. U kunt ook rekening houden met de vereisten voor IOPS, latentie en schijfdoorvoer die meestal worden geschaald met het aantal schijven of het type Premium Storage-schijven. Het aantal IOPS en de doorvoer die door elke schijf moet worden bereikt, kan de schijfgrootte bepalen, met name bij Premium-opslag.

De plaatsing van de databasebestanden, de logboek- en redo-bestanden en het type Azure Storage dat u gebruikt, wordt gedefinieerd door IOPS-, latentie- en doorvoervereisten. Specifiek voor Azure Premium Storage om voldoende IOPS te bereiken, wordt u mogelijk gedwongen om meerdere schijven te gebruiken of een grotere Premium Storage-schijf te gebruiken. Als u meerdere schijven gebruikt, bouwt u een softwarestree over de schijven die de gegevensbestanden of de logboek- en redo-bestanden bevatten. In dergelijke gevallen worden de IOPS en de SLA's voor schijfdoorvoer van de onderliggende Premium Storage-schijven of de maximaal haalbare IOPS van Standard-opslagschijven cumulatief voor de resulterende stripe-set.

Als uw IOPS-vereiste groter is dan wat één VHD kan bieden, moet u het aantal IOPS dat nodig is voor de databasebestanden over een aantal VHD's in balans brengen. De eenvoudigste manier om de IOPS-belasting over schijven te verdelen, is door een softwarestree over de verschillende schijven te bouwen. Plaats vervolgens een aantal gegevensbestanden van de SAP DBMS op de LUN's die uit de softwarestree zijn verwijderd. Het aantal schijven in de stripe wordt aangestuurd door de IOPS-eisen, de vraag naar schijfdoorvoer en de vraag naar volumes.

Windows

We raden u aan om Windows Opslagruimten stripesets te maken op meerdere Azure-VHD's. Gebruik ten minste Windows Server 2012 R2 of Windows Server 2016.

Linux

Alleen M ANTIVIRUSM en Logical Volume Manager (LVM) worden ondersteund voor het bouwen van een software-RAID op Linux. Zie voor meer informatie:

• Software RAID op Linux configureren met M ANTIVIRUSM
• LVM configureren op een linux-VM in Azure met behulp van LVM

Voor Azure Ultra Disk is striping niet nodig omdat u IOPS en schijfdoorvoer kunt definiëren, onafhankelijk van de grootte van de schijf.

Beheerde of niet-beheerde schijven

Een Azure-opslagaccount is een administratieve constructie en ook een onderwerp van beperkingen. Beperkingen verschillen tussen Standard-opslagaccounts en Premium Storage-accounts. Zie schaalbaarheids- en prestatiedoelen voor Azure Storage informatie over mogelijkheden en beperkingen.

Voor standaardopslag geldt een limiet voor de IOPS per opslagaccount. Zie de rij met De totale aanvraagsnelheid in het artikel Azure Storage schaalbaarheids- en prestatiedoelen. Er is ook een initiële limiet voor het aantal opslagaccounts per Azure-abonnement. Balanceer VHD's voor het grotere SAP-landschap over verschillende opslagaccounts om te voorkomen dat de limieten van deze opslagaccounts worden bereikt. Dit is omslachtig werk wanneer u het hebt over een paar honderd virtuele machines met meer dan duizend VHD's.

Het gebruik van standaardopslag voor DBMS-implementaties in combinatie met een SAP-workload wordt niet aanbevolen. Verwijzingen en aanbevelingen voor standaardopslag zijn daarom beperkt tot dit korte artikel

Om het administratieve werk van het plannen en implementeren van VHD's in verschillende Azure-opslagaccounts te voorkomen, heeft Microsoft Azure Managed Disks in 2017 geïntroduceerd. Beheerde schijven zijn beschikbaar voor Standard-opslag en Premium-opslag. De belangrijkste voordelen van beheerde schijven ten opzichte van niet-beheerde schijven zijn:

• Voor beheerde schijven distribueert Azure de verschillende VHD's automatisch tijdens de implementatie over verschillende opslagaccounts. Op deze manier worden opslagaccountlimieten voor gegevensvolume, I/O-doorvoer en IOPS niet bereikt.
• Met behulp van beheerde schijven Azure Storage de concepten van Azure-beschikbaarheidssets. Als de VM deel uitmaakt van een Azure-beschikbaarheidsset, worden de basis-VHD en gekoppelde schijf van een VM geïmplementeerd in verschillende fout- en updatedomeinen.

Als u niet-beheerde schijven wilt converteren naar beheerde schijven, gaat u naar:

• Converteert Windows virtuele machine van niet-beheerde schijven naar beheerde schijven.
• Converteert een virtuele Linux-machine van niet-beheerde schijven naar beheerde schijven.

Caching voor VM's en gegevensschijven

Wanneer u schijven aan VM's bevestigt, kunt u kiezen of het I/O-verkeer tussen de VM en die schijven in Azure Storage in de cache wordt opgeslagen.

In de volgende aanbevelingen wordt uitgenomen dat deze I/O-kenmerken voor standaard DBMS worden gebruikt:

• Het is voornamelijk een leesworkload voor gegevensbestanden van een database. Deze leesresultaten zijn essentieel voor de prestaties van het DBMS-systeem.
• Schrijven op basis van de gegevensbestanden vindt plaats in bursts op basis van controlepunten of een constante stroom. Gemiddeld over een dag zijn er minder schrijf- dan lees-artikelen. In tegenstelling tot het lezen van gegevensbestanden, zijn deze schrijfingen asynchroon en worden er geen gebruikerstransacties opgeslagen.
• Er zijn nauwelijks lees- of redo-bestanden uit het transactielogboek. Uitzonderingen zijn grote I/O's wanneer u back-ups van transactielogboek maakt.
• De belangrijkste belasting voor transactie- of redo-logboekbestanden zijn schrijfbestanden. Afhankelijk van de aard van de workload kunt u I/O-grootten van 4 kB hebben of, in andere gevallen, I/O-grootten van 1 MB of meer.
• Alle schrijf- en schrijf schrijf- en schrijfree op een betrouwbare manier op schijf worden opgeslagen.

Voor standaardopslag zijn dit de mogelijke cachetypen:

• Geen
• Lezen
• Lezen/Schrijven

Voor consistente en deterministische prestaties stelt u de caching op standaardopslag in voor alle schijven die DBMS-gerelateerde gegevensbestanden, logboek- en redo-bestanden en tabelruimte bevatten op GEEN. De caching van de basis-VHD kan de standaardwaarde blijven.

Voor Azure Premium Storage bestaan de volgende cachingopties:

• Geen
• Lezen
• Lezen/schrijven
• Geen + Write Accelerator, wat alleen geldt voor VM's uit de Azure M-serie
• Lezen en Write Accelerator, wat alleen geldt voor VM's uit de Azure M-serie

Voor Premium Storage raden we u aan lees caching te gebruiken voor gegevensbestanden van de SAP-database en geen caching te kiezen voor de schijven met logboekbestanden.

Voor implementaties uit de M-serie raden we u aan Azure Write Accelerator voor uw DBMS-implementatie. Zie Enable Write Accelerator voor meer informatie, beperkingen en implementatie van Azure Write Accelerator.

Voor Ultra disk en Azure NetApp Files worden er geen caching-opties aangeboden.

Niet-persistente Azure-schijven

Azure-VM's bieden niet-persistente schijven nadat een VM is geïmplementeerd. In het geval van het opnieuw opstarten van een VM wordt alle inhoud op die stations gewist. Het is een gegeven dat gegevensbestanden en logboek- en redo-bestanden van databases onder geen enkele omstandigheden op deze niet-persisted stations mogen worden gevonden. Er kunnen uitzonderingen zijn voor sommige databases, waarbij deze niet-persistente stations geschikt kunnen zijn voor tempdb- en temp-tablespaces. Vermijd het gebruik van deze stations voor VM's uit de A-serie, omdat deze niet-gebruikte stations zijn beperkt in doorvoer met die VM-serie.

Zie Understand the temporary drive on Windows VMs in Azure (Inzichtin het tijdelijke station op virtuele Windows in Azure) voor meer informatie.

Windows

Station D in een Azure-VM is een niet-gepersisteerd station, dat wordt back-by door een aantal lokale schijven op het Azure-reken knooppunt. Omdat deze niet wordt bevestigd, gaan alle wijzigingen in de inhoud op station D verloren wanneer de VM opnieuw wordt opgestart. Wijzigingen omvatten bestanden die zijn opgeslagen, mappen die zijn gemaakt en toepassingen die zijn geïnstalleerd.

Linux

Virtuele Linux Azure-VM's worden automatisch gekoppeld aan een station op /mnt/resource dat een niet-gepersisteerd station is dat wordt back-by door lokale schijven op het Azure-reken knooppunt. Omdat deze niet wordt gebruikt, gaan alle wijzigingen in inhoud in /mnt/resource verloren wanneer de VM opnieuw wordt opgestart. Wijzigingen omvatten bestanden die zijn opgeslagen, mappen die zijn gemaakt en toepassingen die zijn geïnstalleerd.

Microsoft Azure Storage tolerantie

Microsoft Azure Storage slaat de basis-VHD, met besturingssysteem en gekoppelde schijven of blobs, op ten minste drie afzonderlijke opslagknooppunten op. Dit type opslag wordt lokaal redundante opslag (LRS) genoemd. LRS is de standaardinstelling voor alle typen opslag in Azure.

Er zijn andere redundantiemethoden. Zie Azure Storage-replicatie voor meer informatie.

Tolerantie van VM-knooppunt

Azure biedt verschillende SLA's voor VM's. Zie voor meer informatie de meest recente release van SLA voor Virtual Machines. Omdat de DBMS-laag essentieel is voor de beschikbaarheid in een SAP-systeem, moet u inzicht hebben in beschikbaarheidssets, Beschikbaarheidszones en onderhoudsgebeurtenissen. Zie Manage the availability of Windows virtual machines in Azure (De beschikbaarheid van virtuele machines in Azure beheren) en Manage the availability of Linux virtual machines in Azure (De beschikbaarheid van virtuele Linux-machines in Azurebeheren) voor meer informatie over deze concepten.

De minimale aanbeveling voor DBMS-productiescenario's met een SAP-workload is:

• Implementeer twee VM's in een afzonderlijke beschikbaarheidsset in dezelfde Azure-regio.
• Voer deze twee VM's uit in hetzelfde virtuele Azure-netwerk en hebben NIC's die zijn gekoppeld vanuit dezelfde subnetten.
• Gebruik databasemethoden om een hot stand-by te houden met de tweede VM. Methoden kunnen worden SQL Server Always On, Oracle Data Guard of HANA-systeemreplicatie.

U kunt ook een derde VM implementeren in een andere Azure-regio en dezelfde databasemethoden gebruiken om een asynchrone replica te leveren in een andere Azure-regio.

Zie deze zelfstudie voor meer informatie over het instellen van Azure-beschikbaarheidssets.

Overwegingen voor Azure-netwerken

Gebruik in grootschalige SAP-implementaties de blauwdruk van Azure Virtual Datacenter. Gebruik deze voor de configuratie van uw virtuele netwerk en machtigingen en roltoewijzingen voor verschillende onderdelen van uw organisatie.

Deze best practices zijn het resultaat van honderden klantimplementaties:

• De virtuele netwerken waar de SAP-toepassing in wordt geïmplementeerd, hebben geen toegang tot internet.
• De database-VM's worden uitgevoerd in hetzelfde virtuele netwerk als de toepassingslaag, gescheiden in een ander subnet van de SAP-toepassingslaag.
• De virtuele machines in het virtuele netwerk hebben een statische toewijzing van het privé-IP-adres. Zie IP-adrestypen en toewijzingsmethoden in Azure voor meer informatie.
• Routeringsbeperkingen van en naar de DBMS-VM's worden niet ingesteld met firewalls die zijn geïnstalleerd op de lokale DBMS-VM's. In plaats daarvan wordt verkeersroutering gedefinieerd met netwerkbeveiligingsgroepen (NSG's).
• Als u verkeer naar de VIRTUELE DBMS-VM wilt scheiden en isoleren, wijst u verschillende NIC's toe aan de VM. Elke NIC krijgt een ander IP-adres en elke NIC wordt toegewezen aan een ander subnet van een virtueel netwerk. Elk subnet heeft verschillende NSG-regels. De isolatie of scheiding van netwerkverkeer is een meting voor routering. Het wordt niet gebruikt om quota voor netwerkdoorvoer in te stellen.

Gebruik twee VM's voor uw dbms-productieimplementatie binnen een Azure-beschikbaarheidsset of tussen twee Azure-beschikbaarheidszones. Gebruik ook afzonderlijke routering voor de SAP-toepassingslaag en het beheer- en bewerkingsverkeer naar de twee DBMS-VM's. Zie de volgende afbeelding:

Gebruik Azure Load Balancer om verkeer om te leiden

Het gebruik van privé virtuele IP-adressen die worden gebruikt in functies zoals SQL Server Always On of HANA-systeemreplicatie vereist de configuratie van een Azure load balancer. De load balancer testpoorten gebruikt om het actieve DBMS-knooppunt te bepalen en het verkeer uitsluitend naar dat actieve database-knooppunt te sturen.

Als er een failover van het database-knooppunt is, hoeft de SAP-toepassing niet opnieuw te worden geconfigureerd. In plaats daarvan maken de meest voorkomende SAP-toepassingsarchitectarchitecten opnieuw verbinding met het privé-virtuele IP-adres. Ondertussen reageert de load balancer op de failover van het knooppunt door het verkeer om te leiden naar het privé virtuele IP-adres naar het tweede knooppunt.

Azure biedt twee verschillende load balancer-SKU's:een basis-SKU en een standaard-SKU. Op basis van de voordelen van de installatie en functionaliteit moet u de Standard-SKU van de Azure-load balancer. Een van de grote voordelen van de Standard-versie van de load balancer is dat het gegevensverkeer niet wordt gerouteerd via de load balancer zelf.

Een voorbeeld van hoe u een interne load balancer kunt configureren, vindt u in het artikel Zelfstudie: Een SQL Server-beschikbaarheidsgroep configureren in Azure Virtual Machines handmatig

Versneld netwerken van Azure

Als u de netwerklatentie tussen azure-VM's verder wilt verminderen, raden we u aan om versneld netwerken van Azure te kiezen. Gebruik deze optie wanneer u Azure-VM's implementeert voor een SAP-workload, met name voor de SAP-toepassingslaag en de SAP DBMS-laag.

Windows

Zie Create a Windows virtual machine with Accelerated Networking(Een virtuele machine Windows met versneld netwerken) voor meer informatie over het implementeren van VM's met versneld netwerken voor Windows.

Linux

Zie Een virtuele Linux-machine maken met versneld netwerken voor meer informatie over Linux-distributie.

Implementatie van hostbewaking

Voor productiegebruik van SAP-toepassingen in virtuele Azure-machines moet SAP hostbewakingsgegevens kunnen ontvangen van de fysieke hosts die de virtuele Azure-machines uitvoeren. Er is een specifiek patchniveau voor de SAP-hostagent vereist dat deze mogelijkheid mogelijk maakt in SAPOSCOL en SAP Host Agent. Het exacte patchniveau wordt beschreven in SAP Note 1409604.

Zie de implementatiehandleiding voor meer informatie over de implementatie van onderdelen die hostgegevens leveren aan SAPOSCOL en SAP Host Agent en het levenscyclusbeheer van deze onderdelen.

Volgende stappen

Zie voor meer informatie over een bepaalde DBMS:

• DBMS-implementatie voor SAP-werkbelasting in virtuele Azure-machines voor SQL Server
• DBMS-implementatie voor SAP-werkbelasting in virtuele Azure-machines voor Oracle
• IBM DB2 Azure Virtual Machines DBMS-implementatie voor SAP-workload
• DBMS-implementatie voor SAP-werkbelasting in virtuele Azure-machines voor SAP ASE
• Implementatie van SAP maxDB, livecache en inhoudsserver in Azure
• Bedieningsgids voor SAP HANA op Azure
• SAP HANA hoge beschikbaarheid voor virtuele Azure-machines
• Back-uphandleiding voor SAP HANA virtuele Azure-machines