Share via

Overwegingen voor DBMS-implementatie van Azure Virtual Machines voor SAP-workload

  • Artikel

Deze handleiding maakt deel uit van de documentatie over het implementeren en implementeren van SAP-software in Microsoft Azure. Lees de plannings- en implementatiehandleiding en artikelen waarnaar u verwijst voordat u deze handleiding leest. In dit document worden de algemene implementatieaspecten van SAP-gerelateerde DBMS-systemen op virtuele Microsoft Azure-machines (VM's) behandeld 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 voor installaties en implementaties van SAP-software op bepaalde platforms vertegenwoordigen.

In dit document worden overwegingen voor het uitvoeren van SAP-gerelateerde DBMS-systemen in Azure-VM's geïntroduceerd. Er zijn enkele verwijzingen naar specifieke DBMS-systemen in dit document. In plaats daarvan worden de specifieke DBMS-systemen verwerkt in andere databasesysteemspecifieke documenten.

Resources

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

De volgende SAP-notities zijn gerelateerd aan SAP in Azure met betrekking tot het gebied dat in dit document wordt behandeld.

Notitienummer Titel
1928533 SAP-toepassingen in Azure: ondersteunde producten en Typen Azure-VM's
2015553 SAP op Microsoft Azure: ondersteuningsvereisten
1999351 Problemen met verbeterde Azure-bewaking voor SAP oplossen
2178632 Belangrijke bewakingsgegevens voor SAP in Microsoft Azure
1409604 Virtualisatie in Windows: Verbeterde bewaking
2191498 SAP op Linux met Azure: Verbeterde bewaking
2039619 SAP-toepassingen in Microsoft Azure met behulp van de Oracle-database: ondersteunde producten en versies
2233094 DB6: SAP-toepassingen in Azure met IBM DB2 voor Linux, UNIX en Windows: aanvullende informatie
2243692 Linux op Microsoft Azure -VM (IaaS): problemen met SAP-licenties
2578899 SUSE Linux Enterprise Server 15: Installatienotitie
1984787 SUSE LINUX Enterprise Server 12: Installatieopmerkingen
2772999 Red Hat Enterprise Linux 8.x: installatie en configuratie
2002167 Red Hat Enterprise Linux 7.x: installatie en upgrade
2069760 Oracle Linux 7.x SAP-installatie en -upgrade
1597355 Aanbeveling voor wisselruimte voor Linux
2799900 Centrale technische opmerking voor Oracle Database 19c
2171857 Oracle Database 12c: bestandssysteemondersteuning op Linux
1114181 Oracle Database 11g: bestandssysteemondersteuning op Linux
2969063 Microcodevalidatie is mislukt in HCMT in Azure
3246210 Azure - HCMT mislukt tijdens sommige schijfprestatietests

Zie de SAP-communitywiki voor informatie over alle SAP-notities voor Linux.

U hebt een werkende kennis van De Architectuur van Microsoft Azure nodig en hoe virtuele Microsoft Azure-machines worden geïmplementeerd en beheerd. Zie de Documentatie van Azure voor meer informatie.

Over het algemeen zijn de installatie en configuratie van Windows, Linux en DBMS in wezen hetzelfde als elke virtuele machine of bare-metalcomputer 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.

Opslagstructuur van een VM voor RDBMS-implementaties

Als u dit hoofdstuk wilt volgen, leest en begrijpt u de informatie die wordt gepresenteerd in:

Voor Azure-blokopslag is het gebruik van beheerde Azure-schijven verplicht. Lees het artikel Inleiding tot beheerde schijven voor Azure-VM's voor meer informatie over door Azure beheerde schijven.

In een basisconfiguratie raden we meestal een implementatiestructuur aan waarbij het besturingssysteem, DBMS en uiteindelijke binaire SAP-bestanden gescheiden zijn van de databasebestanden. U wordt aangeraden afzonderlijke Azure-schijven te gebruiken voor:

  • Het besturingssysteem (basis-VHD of besturingssysteem-VHD)
  • Uitvoerbare bestanden van het databasebeheersysteem
  • SAP-uitvoerbare bestanden zoals /usr/sap
  • DBMS-gegevensbestanden
  • DBMS-logboekbestanden opnieuw uitvoeren

Een configuratie die deze onderdelen in vijf verschillende volumes scheidt, kan leiden tot een hogere tolerantie, omdat overmatig gebruik op één volume niet noodzakelijkerwijs het gebruik van andere volumes beïnvloedt zolang het opslagquotum en de limieten van de VM niet worden overschreden.

De DBMS-gegevens en transactie-/redo-logboekbestanden worden opgeslagen in ondersteuning voor Azure blokopslag of Azure NetApp Files. Azure Files of Azure Premium Files wordt niet ondersteund als opslag voor DBSM-gegevens en/of opnieuw uitvoeren van logboekbestanden met SAP-werkbelasting. Ze worden opgeslagen in afzonderlijke schijven en als logische schijven gekoppeld aan de oorspronkelijke VM van het Azure-besturingssysteem. Voor Linux-implementaties worden verschillende aanbevelingen gedocumenteerd. Lees het artikel Azure Storage-typen voor SAP-workload voor de mogelijkheden en de ondersteuning van de verschillende opslagtypen voor uw scenario. Specifiek voor SAP HANA begint met het artikel SAP HANA Azure-opslagconfiguraties voor virtuele machines.

Wanneer u de schijfindeling plant, zoekt u de beste balans 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 totale opslag- of netwerkdoorvoer die een virtuele machine kan bieden.
  • De latentie die verschillende Azure Storage-typen kunnen bieden.
  • IOPS voor VM-opslag en doorvoerquotum.
  • VM-netwerkquotum voor het geval u NFS gebruikt: verkeer naar NFS-shares telt mee op basis van het netwerkquotum van de VIRTUELE machine en NIET het opslagquotum.
  • VM-SLA's.

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

Elk van de verschillende VM-typen heeft een beperkt aantal gegevensschijven die u kunt koppelen. Een andere beperking is dat alleen bepaalde VM-typen bijvoorbeeld Premium Storage kunnen gebruiken. Normaal gesproken besluit u een bepaald VM-type te gebruiken op basis van cpu- en geheugenvereisten. U moet ook rekening houden met de IOPS-, latentie- en schijfdoorvoervereisten die meestal worden geschaald met het aantal schijven of het type Premium Storage-schijven v1. Het aantal IOPS en de doorvoer die door elke schijf moet worden bereikt, kan de schijfgrootte dicteren, met name met Premium Storage v1. Met Premium Storage v2 of Ultra Disk kunt u ingerichte IOPS en doorvoer selecteren, onafhankelijk van de schijfcapaciteit.

Notitie

Voor DBMS-implementaties raden we u ten zeerste aan Om Azure Premium Storage (v1 en v2), Ultra Disk of Azure NetApp Files gebaseerde NFS-shares te gebruiken voor gegevens, transactielogboeken of opnieuw uitvoeren van bestanden. Het maakt niet uit of u productie- of niet-productiesystemen wilt implementeren. Latentie van Azure Standard HDD of SSD is niet acceptabel voor elk type productiesysteem.

Notitie

Als u de SLA voor één VM van Azure wilt maximaliseren, moeten alle schijven die zijn gekoppeld, Azure Premium Storage (v1 of v2) of Azure Ultra Disk-type zijn, waaronder de basis-VHD (Azure Premium Storage).

Notitie

Het hosten van hoofddatabasebestanden, zoals gegevens en logboekbestanden, van SAP-databases op opslaghardware die zich in co-locatie bevindende datacenters van derden die grenzen aan Azure-datacenters, wordt niet ondersteund. Opslag die wordt geleverd via softwareapparaten die worden gehost in Azure-VM's, worden ook niet ondersteund voor deze use-case. Voor SAP DBMS-workloads wordt alleen opslag die wordt weergegeven als systeemeigen Azure-service ondersteund voor de gegevens- en transactielogboekbestanden van SAP-databases in het algemeen. Verschillende DBMS-opslagtypen kunnen verschillende Azure-opslagtypen ondersteunen. Raadpleeg het artikel Azure Storage-typen voor SAP-werkbelasting voor meer informatie

De plaatsing van de databasebestanden en 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 v1, om voldoende IOPS te bereiken, bent u mogelijk gedwongen om meerdere schijven te gebruiken of een grotere Premium-opslagschijf te gebruiken. Als u meerdere schijven gebruikt, bouwt u een softwarestrook op de schijven die de gegevensbestanden of het logboek bevatten en opnieuw uitvoeren. In dergelijke gevallen worden de IOPS en de schijfdoorvoer-SLA's van de onderliggende Premium Storage-schijven of de maximaal haalbare IOPS van standard-opslagschijven accumulatief voor de resulterende stripeset.

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

Windows-opslagstriping Ramen

U wordt aangeraden Windows Opslagruimten te gebruiken om stripesets te maken op meerdere Azure-VHD's. Gebruik ten minste Windows Server 2012 R2 of Windows Server 2016.

Striping voor Linux-opslag Linux

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

Voor Azure Premium Storage v2 en Ultra-schijf is striping mogelijk niet nodig, omdat u IOPS en schijfdoorvoer onafhankelijk van de grootte van de schijf kunt definiëren.

Notitie

Omdat Azure Storage drie installatiekopieën van de VHD's bewaart, is het niet zinvol om een redundantie te configureren wanneer u stript. U hoeft striping alleen te configureren zodat de I/Os worden verdeeld over de verschillende VHD's.

Beheerde of niet-beheerde schijven

Een Azure-opslagaccount is een beheerconstructie en is ook onderhevig aan beperkingen. Zie Azure Storage-schaalbaarheids- en prestatiedoelen voor meer informatie over mogelijkheden en beperkingen. Voor standaardopslag moet u er rekening mee houden dat er een limiet geldt voor de IOPS per opslagaccount. Zie de rij met de totale aanvraagsnelheid in het artikel Schaalbaarheids- en prestatiedoelen van Azure Storage. Er is ook een initiële limiet voor het aantal opslagaccounts per Azure-abonnement. Vanaf 2017 heeft Azure de concepten van Azure Managed Disks geïntroduceerd waarmee u het beheer van opslagaccounts kunt regelen. Het gebruik van beheerde Azure-schijven is de standaardinstelling voor implementatie voor SAP-werkbelasting in Azure.

Belangrijk

Gezien de voordelen van Azure Managed Disks, is het verplicht dat u Azure Managed Disks gebruikt voor uw DBMS-implementaties en SAP-implementaties in het algemeen.

Als u een SAP-workload hebt die nog geen beheerde schijven gebruikt, raadpleegt u het volgende om te converteren van niet-beheerde schijven naar beheerde schijven:

Caching voor VM's en gegevensschijven

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

Bij de volgende aanbevelingen wordt uitgegaan van deze I/O-kenmerken voor standaard DBMS:

  • Het is meestal een leesworkload voor gegevensbestanden van een database. Deze leesbewerkingen 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 gedurende een dag, zijn er minder schrijfbewerkingen dan leesbewerkingen. In tegenstelling tot leesbewerkingen uit gegevensbestanden zijn deze schrijfbewerkingen asynchroon en bevatten ze geen gebruikerstransacties.
  • Er zijn nauwelijks leesbewerkingen uit het transactielogboek of redo-bestanden. Uitzonderingen zijn grote I/Os wanneer u back-ups van transactielogboeken uitvoert.
  • De belangrijkste belasting voor transactie- of redo-logboekbestanden is schrijfbewerkingen. Afhankelijk van de aard van de werkbelasting kunt u I/Os hebben van slechts 4 kB of, in andere gevallen, I/O-grootten van 1 MB of meer.
  • Alle schrijfbewerkingen moeten op een betrouwbare manier op schijf worden bewaard.

Voor Azure Premium Storage v1 zijn de volgende cacheopties beschikbaar:

  • Geen
  • Read
  • Lezen/schrijven
  • None + Write Accelerator, alleen voor vm's uit de Azure M-serie
  • Read + Write Accelerator, alleen voor vm's uit de Azure M-serie

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

Notitie

Met sommige van de nieuwe VM-typen M(b)v3 kan het gebruik van Premium SSD v1-opslag in de cache leiden tot lagere IOPS-snelheid en -schrijfsnelheid en -doorvoer dan u krijgt als u geen leescache gebruikt.

Voor implementaties uit de M-serie wordt u aangeraden alleen Azure Write Accelerator te gebruiken voor de schijven van uw logboekbestanden. Zie Write Accelerator inschakelen voor meer informatie, beperkingen en implementatie van Azure Write Accelerator.

Voor Premium Storage v2, Ultra Disk en Azure NetApp Files worden er geen cacheopties aangeboden.

Niet-bestaande Azure-schijven

Virtuele Azure-machines bieden niet-persistente schijven nadat een VIRTUELE machine is geïmplementeerd. Als een virtuele machine opnieuw wordt opgestart, kan alle inhoud op deze stations worden gewist. Het is een gegeven dat gegevensbestanden en logboek- en redobestanden van databases onder geen enkele omstandigheden mogen worden gevonden op deze niet-gepersisteerde stations. Er kunnen uitzonderingen zijn voor sommige databases, waarbij deze niet-gepersiste stations geschikt kunnen zijn voor tempdb- en tijdelijke tabelruimten.

Zie Inzicht in het tijdelijke station op Windows-VM's in Azure voor meer informatie.

Niet-gepersisteerde Windows-schijf Ramen

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

Linuxnonpersisted schijf Linux

Linux Azure-VM's koppelen automatisch een station op /mnt/resource dat een niet-gepersisteerd station is dat wordt ondersteund door lokale schijven op het Azure-rekenknooppunt. Omdat deze niet-persist is, gaan alle wijzigingen in inhoud in /mnt/resource verloren wanneer de virtuele machine opnieuw wordt opgestart. Wijzigingen omvatten bestanden die zijn opgeslagen, mappen die zijn gemaakt en toepassingen die zijn geïnstalleerd.

Tolerantie voor Microsoft Azure Storage

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.

Notitie

Azure Premium Storage v1 en v2, Ultra disk en Azure NetApp Files zijn het aanbevolen type opslag voor DBMS-VM's en schijven die database opslaan en opnieuw opslaan en opnieuw uitvoeren. Met uitzondering van Premium Storage v1 is LRS de enige beschikbare redundantiemethode voor deze opslagtypen. Als gevolg hiervan moet u databasemethoden configureren om databasegegevensreplicatie in te schakelen in een andere Azure-regio of beschikbaarheidszone. Databasemethoden omvatten SQL Server Always On, Oracle Data Guard en HANA-systeemreplicatie.

Tolerantie van VM-knooppunten

Azure biedt verschillende SLA's voor VM's. Zie de meest recente versie van sla voor virtuele machines voor meer informatie. Omdat de DBMS-laag essentieel is voor beschikbaarheid in een SAP-systeem, moet u verschillende implementatietypen en onderhoudsevenementen begrijpen. Zie De beschikbaarheid van virtuele machines in Azure beheren voor meer informatie over deze concepten.

De minimale aanbeveling voor productie-DBMS-scenario's met een SAP-workload is het volgende:

  • Implementeer twee VM's met behulp van het gekozen implementatietype in dezelfde Azure-regio.
  • Voer deze twee VM's uit in hetzelfde virtuele Azure-netwerk en laat NIC's uit dezelfde subnetten zijn gekoppeld.
  • Gebruik databasemethoden om een hot stand-by te houden met de tweede VIRTUELE machine. Methoden kunnen SQL Server Always On, Oracle Data Guard of HANA-systeemreplicatie zijn.

U kunt ook een derde VIRTUELE machine implementeren in een andere Azure-regio en dezelfde databasemethoden gebruiken om een asynchrone replica in een andere Azure-regio op te geven.

Overwegingen voor Azure-netwerken

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

Deze aanbevolen procedures zijn het resultaat van duizenden implementaties van klanten:

  • De virtuele netwerken waarop de SAP-toepassing 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 DBMS-VM wilt scheiden en isoleren, wijst u verschillende NIC's toe aan de VIRTUELE machine. 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 in te stellen voor netwerkdoorvoer.

Notitie

Het toewijzen van statische IP-adressen via Azure betekent dat u deze toewijst aan afzonderlijke virtuele NIC's. Wijs geen statische IP-adressen binnen het gastbesturingssystemen toe aan een virtuele NIC. Sommige Azure-services zoals Azure Backup zijn afhankelijk van het feit dat ten minste de primaire virtuele NIC in het gastbesturingssystem is ingesteld op DHCP en niet op statische IP-adressen. Zie Problemen met back-ups van virtuele Azure-machines oplossen voor meer informatie. Als u meerdere statische IP-adressen aan een virtuele machine wilt toewijzen, wijst u meerdere virtuele NIC's toe aan een virtuele machine.

Waarschuwing

Het configureren van virtuele netwerkapparaten in het communicatiepad tussen de SAP-toepassing en de DBMS-laag van een SAP NetWeaver-, Hybris- of S/4HANA-systeem wordt niet ondersteund. Deze beperking heeft te maken met functionaliteit en prestatieredenen. Het communicatiepad tussen de SAP-toepassingslaag en de DBMS-laag moet direct zijn. De beperking omvat geen toepassingsbeveiligingsgroep (ASG) en NSG-regels als deze ASG- en NSG-regels een direct communicatiepad toestaan. Dit omvat ook verkeer naar NFS-shares die DBMS-gegevens hosten en logboekbestanden opnieuw uitvoeren.

Andere scenario's waarin virtuele netwerkapparaten niet worden ondersteund, bevinden zich in:

Virtuele netwerkapparaten in communicatiepaden kunnen eenvoudig de netwerklatentie tussen twee communicatiepartners verdubbelen. Ze kunnen ook de doorvoer beperken in kritieke paden tussen de SAP-toepassingslaag en de DBMS-laag. In sommige scenario's van klanten kunnen virtuele netwerkapparaten ertoe leiden dat Pacemaker Linux-clusters mislukken. Dit zijn gevallen waarin communicatie tussen de Linux Pacemaker-clusterknooppunten via een virtueel netwerkapparaat met hun SBD-apparaat communiceert.

Belangrijk

Een ander ontwerp dat niet wordt ondersteund, is de scheiding van de SAP-toepassingslaag en de DBMS-laag in verschillende virtuele Azure-netwerken die niet met elkaar zijn gekoppeld. U wordt aangeraden de SAP-toepassingslaag en DBMS-laag te scheiden met behulp van subnetten in een virtueel Azure-netwerk in plaats van met behulp van verschillende virtuele Azure-netwerken.

Als u besluit de aanbeveling niet te volgen en in plaats daarvan de twee lagen in verschillende virtuele netwerken te scheiden, moeten de twee virtuele netwerken worden gekoppeld.

Houd er rekening mee dat netwerkverkeer tussen twee gekoppelde virtuele Azure-netwerken onderhevig is aan overdrachtskosten. Enorm gegevensvolume dat uit veel terabytes bestaat, wordt uitgewisseld tussen de SAP-toepassingslaag en de DBMS-laag. U kunt aanzienlijke kosten verzamelen als de SAP-toepassingslaag en DBMS-laag worden gescheiden tussen twee gekoppelde virtuele Azure-netwerken.

Azure Load Balancer gebruiken om verkeer om te leiden

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

Als er een failover van het databaseknooppunt is, hoeft de SAP-toepassing niet opnieuw te worden geconfigureerd. In plaats daarvan maken de meest voorkomende SAP-toepassingsarchitecturen 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 eenvoudige 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 gebruiken. 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 hoe u een interne load balancer kunt configureren, vindt u in het artikel Zelfstudie: Een SQL Server-beschikbaarheidsgroep configureren op virtuele Azure-machines handmatig

Notitie

Er zijn verschillen in gedrag van de basis- en standaard-SKU met betrekking tot de toegang tot openbare IP-adressen. De manier waarop u de beperkingen van de Standard-SKU voor toegang tot openbare IP-adressen kunt omzeilen, wordt beschreven in het document Openbare eindpuntconnectiviteit voor virtuele machines met behulp van Azure Standard Load Balancer in scenario's met hoge beschikbaarheid van SAP

Implementatie van hostbewaking

Voor productiegebruik van SAP-toepassingen in virtuele Azure-machines vereist SAP de mogelijkheid om hostbewakingsgegevens op te halen van de fysieke hosts waarop de virtuele Azure-machines worden uitgevoerd. Er is een specifiek patchniveau voor de SAP Host Agent vereist waarmee deze mogelijkheid in SAPOSCOL en SAP Host Agent mogelijk wordt. Het exacte patchniveau wordt beschreven in SAP Note 1409604.

Voor meer informatie over de implementatie van onderdelen die hostgegevens leveren aan SAPOSCOL en SAP Host Agent en het levenscyclusbeheer van deze onderdelen, begint u met het artikel De Azure VM-extensie implementeren voor SAP-oplossingen.

Volgende stappen

Zie voor meer informatie over een bepaalde DBMS: