Voer SAP HANA voor virtuele Linux-machines uit in een opschaalarchitectuur in Azure

Deze referentiearchitectuur toont een set bewezen procedures voor het uitvoeren van SAP HANA in een maximaal beschikbare, opschaalomgeving die ondersteuning biedt voor herstel na noodgevallen in Azure. Deze implementatie is alleen gericht op de databaselaag.

Architectuur

Deze referentiearchitectuur beschrijft een gemeenschappelijk productiesysteem. U kunt de grootten van de virtuele machines kiezen om tegemoet te komen aan de behoeften van uw organisatie. Deze configuratie kan ook worden beperkt tot één virtuele machine, afhankelijk van de bedrijfsvereisten.

In het volgende diagram ziet u een referentiearchitectuur voor SAP HANA in Azure:

Download een Visio-bestand met de diagrammen in dit artikel.

Workflow

Deze referentiearchitectuur beschrijft een typische SAP HANA-database die wordt uitgevoerd in Azure, in een maximaal beschikbare implementatie om de beschikbaarheid van het systeem te maximaliseren. De architectuur en de bijbehorende onderdelen kunnen worden aangepast op basis van bedrijfsvereisten (RTO, RPO, uptime verwachtingen, systeemrol) en mogelijk beperkt tot één VIRTUELE machine. De netwerkindeling is vereenvoudigd om de architectuurprincipals van een dergelijke SAP-omgeving te demonstreren en niet bedoeld om een volledig bedrijfsnetwerk te beschrijven.

Netwerken

Virtuele netwerken. De Azure Virtual Network-service verbindt Azure-resources met elkaar met verbeterde beveiliging. In deze architectuur maakt het virtuele netwerk verbinding met een on-premises omgeving via een ExpressRoute-gateway die is geïmplementeerd in de hub van een stertopologie. DE SAP HANA-database bevindt zich in een eigen virtueel spoke-netwerk. De virtuele spoke-netwerken bevatten één subnet voor de virtuele databasemachines (VM's).

Als toepassingen die verbinding maken met SAP HANA worden uitgevoerd op VM's, moeten de toepassings-VM's zich in hetzelfde virtuele netwerk bevinden, maar binnen een toegewezen toepassingssubnet. Als sap HANA-verbinding niet de primaire database is, kunnen de toepassings-VM's zich ook in andere virtuele netwerken bevinden. Door te scheiden in subnetten per workload is het eenvoudiger om netwerkbeveiligingsgroepen (NSG) in te schakelen om alleen beveiligingsregels in te stellen die van toepassing zijn op SAP HANA-VM's.

Zone-redundante gateway. Een gateway verbindt afzonderlijke netwerken en breidt uw on-premises netwerk uit naar het virtuele Azure-netwerk. U wordt aangeraden ExpressRoute te gebruiken om privéverbindingen te maken die niet via het openbare internet gaan. U kunt ook een site-naar-site-verbinding gebruiken. Azure ExpressRoute- of VPN-gateways kunnen worden geïmplementeerd in meerdere zones om te voorkomen dat er zonefouten optreden. Zie zone-redundante virtuele netwerkgateways om inzicht te hebben in de verschillen tussen een zonegebonden implementatie en een zone-redundante implementatie. De GEBRUIKTE IP-adressen moeten standaard-SKU zijn voor een zone-implementatie van de gateways.

Netwerkbeveiligingsgroepen (NSG). Als u binnenkomend en uitgaand netwerkverkeer van het virtuele netwerk wilt beperken, maakt u netwerkbeveiligingsgroepen die op hun beurt zijn toegewezen aan specifieke subnetten. DB- en toepassingssubnetten worden beveiligd met workloadspecifieke NSG's.

Toepassingsbeveiligingsgroepen (ASG). Gebruik toepassingsbeveiligingsgroepen in plaats van expliciete IP-adressen om nauwkeurig netwerkbeveiligingsbeleid binnen uw NSG's te definiëren op basis van workloads die zijn gericht op toepassingen. Hiermee kunt u netwerkinterfaces van VM's op naam groeperen en u helpen bij het beveiligen van toepassingen door verkeer van vertrouwde segmenten van uw netwerk te filteren.

Netwerkinterfacekaarten (NIC's). Netwerkinterfacekaarten maken alle communicatie tussen virtuele machines in een virtueel netwerk mogelijk. Traditionele on-premises SAP-implementaties implementeren meerdere NIC's per computer om beheerverkeer van bedrijfsverkeer te scheiden.

In Azure is het niet nodig om meerdere NIC's te gebruiken om prestatieredenen. Meerdere NIC's delen dezelfde netwerkdoorvoerlimiet van een virtuele machine. Maar als uw organisatie verkeer moet scheiden, kunt u meerdere NIC's per VM implementeren en elke NIC verbinden met een ander subnet. Vervolgens kunt u netwerkbeveiligingsgroepen gebruiken om verschillende beleidsregels voor toegangsbeheer af te dwingen voor elk subnet.

Azure NIC's ondersteunen meerdere IP-adressen. Deze ondersteuning voldoet aan de aanbevolen SAP-procedure voor het gebruik van virtuele hostnamen voor installaties. Zie SAP-notitie 962955 voor een volledig overzicht. (Voor toegang tot SAP-notities hebt u een SAP Service Marketplace-account nodig.)

Virtuele machines

Deze architectuur maakt gebruik van virtuele machines (VM). Azure biedt een schaal van één knooppunt tot 23,5 Tebibytes (TiB) aan geheugen op virtuele machines. De sap-gecertificeerde en ondersteunde SAP HANA-hardwaremap bevat de virtuele machines die zijn gecertificeerd voor de SAP HANA-database. Zie SAP Note 1928533 - SAP-toepassingen op Microsoft Azure: ondersteunde producten en azure-VM-typen voor meer informatie over SAP-ondersteuning voor typen virtuele machines en metrische gegevens over doorvoer (SAPS). (Voor toegang tot deze en andere SAP-notities is een SAP Service Marketplace-account vereist.)

Microsoft en SAP certificeren gezamenlijk een reeks virtuele-machinegrootten voor SAP HANA-workloads. Kleinere implementaties kunnen bijvoorbeeld worden uitgevoerd op een virtuele Edsv4 - of Edsv5-machine met 160 GiB of meer RAM-geheugen. Voor de ondersteuning van de grootste SAP HANA-geheugengrootten op virtuele machines, net zo veel als 23 TiB, kunt u virtuele machines uit de Mv2-serie gebruiken. M208-typen virtuele machines bereiken ongeveer 260.000 SAPS en M832ixs virtuele machinetypen bereiken ongeveer 795.900 SAPS.

Virtuele machines van de tweede generatie (Gen2). Wanneer u VM's implementeert, kunt u virtuele machines van de eerste of tweede generatie gebruiken. Vm's van de tweede generatie ondersteunen belangrijke functies die niet beschikbaar zijn voor VM's van de eerste generatie. Voor SAP HANA is dit met name belangrijk omdat sommige VM-families, zoals Mv2 en Mdsv2, alleen worden ondersteund als Gen2-VM's. Op dezelfde manier vereist SAP op Azure-certificering voor sommige nieuwere VM's mogelijk dat ze alleen Gen2 zijn voor volledige ondersteuning, zelfs als Azure beide toestaat. Zie de details in SAP Note 1928533 - SAP-toepassingen in Microsoft Azure: ondersteunde producten en azure-VM-typen.

Omdat alle andere VM's die SAP HANA ondersteunen, de keuze van alleen Gen2 of Gen1+2 selectief toestaan, raden we u aan om alle SAP-VM's alleen als Gen2 te implementeren. Dit geldt ook voor VM's met weinig geheugenvereisten. Zelfs de kleinste 160 GiB SAP HANA-VM kan worden uitgevoerd als Gen2-VM en kan, wanneer de toewijzing ongedaan wordt gemaakt, worden gewijzigd in de grootste VM die beschikbaar is in uw regio en abonnement.

Nabijheidsplaatsingsgroepen (PPG). Om de netwerklatentie te optimaliseren, kunt u nabijheidsplaatsingsgroepen gebruiken, die de voorkeur geven aan collocatie, wat betekent dat virtuele machines zich in hetzelfde datacenter bevinden om de latentie tussen SAP HANA en het verbinden van toepassings-VM's te minimaliseren. Voor SAP HANA-architectuur zelf zijn er geen PPG's nodig. Ze zijn alleen een optie voor het verplaatsen van SAP HANA met VM's in de toepassingslaag. Vanwege mogelijke beperkingen met PPG's, moet het toevoegen van de database AvSet aan de PPG van het SAP-systeem sparseerbaar zijn en alleen wanneer dit nodig is voor latentie tussen SAP-toepassing en databaseverkeer. Zie de gekoppelde documentatie voor meer informatie over de gebruiksscenario's van PPG's. Aangezien PPG's workloads beperken tot één datacenter, kan een PPG niet meerdere beschikbaarheidszones omvatten.

Onderdelen

• Azure Virtual Network
• Azure ExpressRoute
• Azure Virtual Machines
• Azure NetApp Files
• Azure-belastingsverdeling
• Azure Disk Storage

Overwegingen

In deze sectie worden belangrijke overwegingen beschreven voor het uitvoeren van SAP HANA in Azure.

Schaalbaarheid

Met deze architectuur wordt SAP HANA uitgevoerd op virtuele machines die maximaal 23 TiB in één exemplaar kunnen schalen.

Als uw workload de maximale grootte van de virtuele machine overschrijdt, raden we u aan om HANA-configuraties met meerdere knooppunten te gebruiken. Voor OLTP-toepassingen (Online Transaction Processing) kan de totale capaciteit van het scale-outgeheugen zo hoog zijn als 4 x 23 TiB. Voor OLAP-toepassingen (online analytical processing) kan de capaciteit van het scale-outgeheugen zo hoog zijn als 16 x 7,6 TiB. U kunt SAP HANA bijvoorbeeld implementeren in een uitschaalconfiguratie met stand-by op virtuele machines, waarop Red Hat Enterprise Linux of SUSE Linux Enterprise Server wordt uitgevoerd, met behulp van Azure NetApp Files voor de gedeelde opslagvolumes.

Storage

Deze architectuur maakt gebruik van door Azure beheerde schijven voor opslag op de virtuele machines of Azure NetApp Files. Richtlijnen voor opslagimplementatie met beheerde schijven worden uitgebreid beschreven in het document met opslagconfiguraties voor virtuele AZURE-machines in SAP HANA. Als alternatief voor beheerde schijven kunnen Azure NetApp Files NFS-volumes worden gebruikt als opslagoplossing voor SAP HANA.

Voor hoge invoer-/uitvoerbewerkingen per seconde (IOPS) en schijfopslagdoorvoer zijn de algemene procedures voor optimalisatie van opslagvolumeprestaties ook van toepassing op de Indeling van Azure-opslag. Als u bijvoorbeeld meerdere schijven combineert met LVM om een gestreept schijfvolume te maken, worden de IO-prestaties verbeterd. Azure Disk Caching speelt ook een belangrijke rol bij het bereiken van de vereiste IO-prestaties.

Voor SAP HANA-logboekschijven die worden uitgevoerd op Azure Premium SSD v1, gebruikt u een van de volgende technologieën op locaties die /hana/log bevatten voor productie:

• Write Accelerator (op VM's uit de M-serie)
• Ultraschijven (op VM's uit de M- of E-serie)
• Azure NetApp Files (op VM's uit de M- of E-serie)

Deze technologieën zijn nodig om consistent te voldoen aan de vereiste opslaglatentie van minder dan 1 ms.

Azure Premium SSD v2 is ontworpen voor prestatiekritieke workloads zoals SAP. Write Accelerator is niet vereist wanneer /hana/log wordt uitgevoerd op Premium SSD v2. Zie Een Premium SSD v2 implementeren voor informatie over de voordelen en huidige beperkingen van deze opslagoplossing.

Zie SAP Note 1943937 - Hulpprogramma voor hardwareconfiguratiecontrole voor meer informatie over de prestatievereisten van SAP HANA.

• Kostenbewust opslagontwerp voor niet-productiesystemen. Voor SAP HANA-omgevingen waarvoor in alle situaties geen maximale opslagprestaties nodig zijn, kunt u een opslagarchitectuur gebruiken die is geoptimaliseerd voor kosten. Deze keuze voor opslagoptimalisatie kan worden toegepast op weinig gebruikte productiesystemen of sommige niet-productie SAP HANA-omgevingen. De optie voor kosten geoptimaliseerde opslag maakt gebruik van een combinatie van Standard SSD's in plaats van de Premium- of Ultra-SSD's die worden gebruikt voor productieomgevingen. Het combineert ook /hana/data - en /hana/log-bestandssystemen op één set schijven. Richtlijnen en aanbevolen procedures zijn beschikbaar voor de meeste VM-grootten. Als u Azure NetApp Files voor SAP HANA gebruikt, kunt u kleinere volumes gebruiken om hetzelfde doel te bereiken.

• Het formaat van de opslag wijzigen bij omhoog schalen. Wanneer u de grootte van een virtuele machine wijzigt vanwege gewijzigde bedrijfsbehoeften of vanwege een groeiende databasegrootte, kan de opslagconfiguratie veranderen. ondersteuning voor Azure online schijfuitbreiding, zonder onderbreking van de service. Bij een gestreepte schijfinstallatie, zoals wordt gebruikt voor SAP HANA, moet de grootte van alle schijven in de volumegroep gelijk worden aangepast. De toevoeging van meer schijven aan een volumegroep kan de gestreepte gegevens mogelijk onevenwichtig opheffen. Als u meer schijven aan een opslagconfiguratie toevoegt, is het veel beter om een nieuw opslagvolume te maken op nieuwe schijven. Kopieer vervolgens de inhoud tijdens downtime en wijzig koppelpunten. Ten slotte verwijdert u de oude volumegroep en onderliggende schijven.

• Azure NetApp Files-toepassingsvolumegroep. Voor implementaties met SAP HANA-bestanden die zijn opgenomen in Azure NetApp Files NFS-volumes, kunt u met toepassingsvolumegroepen alle volumes implementeren volgens de aanbevolen procedures. Dit proces zorgt ook voor optimale prestaties voor uw SAP HANA-database. Er zijn details beschikbaar over hoe u doorgaat met dit proces. Hiervoor is handmatige interventie vereist. Wacht enige tijd voor het maken.

Hoge beschikbaarheid

In de voorgaande architectuur ziet u een maximaal beschikbare implementatie, met SAP HANA op twee of meer virtuele machines. De volgende onderdelen worden gebruikt.

Load balancers.Azure Load Balancer wordt gebruikt om verkeer te distribueren naar virtuele SAP HANA-machines. Wanneer u Azure Load Balancer opneemt in een zonegebonden implementatie van SAP, moet u ervoor zorgen dat u de Standard SKU-load balancer selecteert. De Basic SKU balancer biedt geen ondersteuning voor zonegebonden redundantie. In deze architectuur fungeert Load Balancer als het virtuele IP-adres voor SAP HANA. Netwerkverkeer wordt verzonden naar de actieve VM waarop het primaire database-exemplaar wordt uitgevoerd. SAP HANA-architectuur met actief/lezen-functionaliteit is beschikbaar (SLES/RHEL), waarbij een tweede virtueel IP-adres dat is geadresseerd op de load balancer wordt gebruikt om netwerkverkeer naar het secundaire SAP HANA-exemplaar op een andere VIRTUELE machine te leiden voor leesintensieve workloads.

De Standard Load Balancer biedt standaard een beveiligingslaag. Virtuele machines die zich achter de Standard Load Balancer bevinden, hebben geen uitgaande internetverbinding. Als u uitgaand internet in deze virtuele machines wilt inschakelen, moet u de Standard Load Balancer-configuratie bijwerken. Daarnaast kunt u ook een Azure NAT-gateway gebruiken om uitgaande connectiviteit te krijgen.

Voor SAP HANA-databaseclusters moet u Direct Server Return (DSR) inschakelen, ook wel drijvende IP genoemd. Met deze functie kan de server reageren op het IP-adres van de front-end van de load balancer. Met deze directe verbinding blijft de load balancer het knelpunt in het pad van gegevensoverdracht.

Implementatieopties. In Azure kan de implementatie van SAP-workloads regionaal of zonegebonden zijn, afhankelijk van de beschikbaarheids- en tolerantievereisten van de SAP-toepassingen. Azure biedt verschillende implementatieopties, zoals Virtual Machine Scale Sets met Flexibele indeling (FD=1), beschikbaarheidszones en beschikbaarheidssets, om de beschikbaarheid van resources te verbeteren. Zie architectuur met hoge beschikbaarheid en scenario's voor SAP NetWeaver voor een uitgebreid inzicht in de beschikbare implementatieopties en hun toepasbaarheid in verschillende Azure-regio's (inclusief zones, binnen één zone of in een regio zonder zones).

SAP HANA. Voor hoge beschikbaarheid wordt SAP HANA uitgevoerd op twee of meer virtuele Linux-machines. SAP HANA System Replication (HSR) wordt gebruikt voor het repliceren van gegevens tussen de primaire en secundaire SAP HANA-systemen (replica). HSR wordt ook gebruikt voor herstel na noodgevallen tussen regio's of zones. Afhankelijk van de latentie in de communicatie tussen uw virtuele machines kan synchrone replicatie binnen een regio worden gebruikt. HSR tussen regio's voor herstel na noodgevallen wordt in de meeste gevallen asynchroon uitgevoerd.

Voor het Linux Pacemaker-cluster moet u bepalen welk clusterafschermingsmechanisme moet worden gebruikt. Clusterafscheiding is het proces van het isoleren van een mislukte VM van het cluster en het opnieuw opstarten ervan. Voor RedHat Enterprise Linux (RHEL) is azure fence agent het enige ondersteunde fencing-mechanisme voor Pacemaker in Azure. Voor SUSE Linux Enterprise Server (SLES) kunt u azure fence agent of STONITH Block Device (SBD) gebruiken. Vergelijk de failovertijden voor elke oplossing en kies, als er een verschil is, een oplossing op basis van uw bedrijfsvereisten voor hersteltijddoelstelling (RTO).

Azure Fence-agent. Deze fencingmethode is afhankelijk van de Azure ARM-API, waarbij Pacemaker een query uitvoert op de ARM-API over de status van beide SAP HANA-VM's in het cluster. Als één VM mislukt, bijvoorbeeld als het besturingssysteem niet reageert of vm-crasht, gebruikt de clusterbeheerder opnieuw de ARM-API om de VIRTUELE machine opnieuw op te starten en, indien nodig, mislukt de SAP HANA-database naar het andere, actieve knooppunt. Voor dit doel wordt een SERVICE Name Principal (SPN) met een aangepaste rol gebruikt om vm's op te vragen en opnieuw op te starten om te autoriseren voor de ARM-API. Er is geen andere infrastructuur nodig, de SBD-VM's in de architectuurtekeningen worden niet geïmplementeerd als de Azure Fence-agent wordt gebruikt.

SBD. STONITH-blokapparaat (SBD) maakt gebruik van een schijf die wordt geopend als blokapparaat (onbewerkt, zonder bestandssysteem) door de clusterbeheerder. Deze schijf, of schijven indien meerdere, fungeert als stem. Elk van de twee clusterknooppunten waarop SAP HANA wordt uitgevoerd, heeft regelmatig toegang tot de SDB-schijven en lees-/schrijfbewerkingen. Daarom kent elk clusterknooppunt de status van de andere zonder dat dit alleen afhankelijk is van netwerken tussen de VM's.

Bij voorkeur worden drie kleine VM's geïmplementeerd in een beschikbaarheidsset of een beschikbaarheidszone-installatie. Elke VM die kleine delen van een schijf exporteert als een blokapparaat dat wordt geopend door de twee SAP HANA-clusterknooppunten. Drie SBD-VM's zorgen ervoor dat er voldoende stemleden beschikbaar zijn in het geval van geplande of ongeplande downtime voor een SBD-VM.

U kunt ook SBD-VM's gebruiken. In plaats daarvan kan een gedeelde Azure-schijf worden gebruikt. De SAP HANA-clusterknooppunten hebben vervolgens toegang tot de enkele gedeelde schijf. De gedeelde schijf kan lokaal (LRS) of zonegebonden (ZRS) redundant zijn, als ZRS beschikbaar is in uw Azure-regio.

Herstel na noodgeval

In de volgende architectuur ziet u een HANA-productieomgeving in Azure die herstel na noodgevallen biedt. De architectuur bevat beschikbaarheidszones.

Zie overzicht van herstel na noodgevallen en infrastructuurrichtlijnen voor SAP-workload en richtlijnen voor herstel na noodgevallen voor SAP-toepassingen voor herstel na noodgeval voor dr-strategieën en implementatiedetails.

Naast een lokale implementatie met hoge beschikbaarheid met twee knooppunten biedt HSR ondersteuning voor multitier - en multitarget-replicatie . HSR ondersteunt daarom replicatie tussen zones en regio's. Multitarget-replicatie is beschikbaar voor SAP HANA 2.0 SPS 03 en hoger.

Zorg ervoor dat u de resourcecapaciteit van uw doelregio controleert.

Azure NetApp Files. Als optie kan Azure NetApp Files worden gebruikt om een schaalbare en krachtige opslagoplossing te bieden voor SAP HANA-gegevens en logboekbestanden. Azure NetApp Files ondersteunt momentopnamen voor snelle back-up, herstel en lokale replicatie. Voor replicatie van inhoud tussen regio's kan Replicatie tussen regio's van Azure NetApp Files worden gebruikt om de momentopnamegegevens tussen twee regio's te repliceren. Details over replicatie tussen regio's en een technisch document waarin alle aspecten voor herstel na noodgevallen met Azure NetApp Files worden beschreven, zijn beschikbaar.

Backup

Er kan op veel manieren een back-up van SAP HANA-gegevens worden gemaakt. Nadat u naar Azure bent gemigreerd, kunt u alle bestaande back-upoplossingen van partners blijven gebruiken die u al hebt. Azure biedt twee systeemeigen benaderingen: back-up op SAP HANA-bestandsniveau en Azure Backup voor SAP HANA via de Backint-interface.

Voor back-ups op SAP HANA-bestandsniveau kunt u het hulpprogramma van uw keuze gebruiken, zoals hdbsql of SAP HANA Studio, en de back-upbestanden opslaan op een lokaal schijfvolume. Een veelvoorkomend koppelpunt voor dit back-upvolume is /hana/backup. Uw back-upbeleid definieert de bewaarperiode voor gegevens op het volume. Zodra de back-up is gemaakt, moet een geplande taak de back-upbestanden kopiëren naar Azure Blob-opslag voor veilige bewaring. De lokale back-upbestanden worden bewaard voor expedient herstel.

Azure Backup biedt een eenvoudige, hoogwaardige oplossing voor workloads die worden uitgevoerd op virtuele machines. Azure Backup voor SAP HANA biedt volledige integratie met de BACK-upcatalogus van SAP HANA en garandeert databaseconsistente, volledige of herstel naar een bepaald tijdstip. Azure Backup is BackInt-gecertificeerd door SAP. Zie ook de veelgestelde vragen en ondersteuningsmatrix van Azure Backup.

Azure NetApp Files biedt ondersteuning voor back-ups op basis van momentopnamen. Integratie met SAP HANA voor toepassingsconsistente momentopnamen vindt plaats via het hulpprogramma Azure-toepassing Consistent Snapshot (AzAcSnap). De gemaakte momentopnamen kunnen worden gebruikt voor herstel naar een nieuw volume voor systeemherstel of het kopiëren van de SAP HANA-database. Momentopnamen die zijn gemaakt, kunnen worden gebruikt voor herstel na noodgevallen, waarbij deze fungeert als herstelpunt met SAP HANA-logboeken die zijn opgeslagen op een ander NFS-volume.

Controleren

Als u uw workloads in Azure wilt bewaken, kunt u met Azure Monitor uitgebreid telemetriegegevens verzamelen, analyseren en er actie op ondernemen vanuit uw cloud- en on-premises omgevingen.

Voor SAP-toepassingen die worden uitgevoerd op SAP HANA en andere belangrijke databaseoplossingen, raadpleegt u Azure Monitor voor SAP-oplossingen voor meer informatie over hoe Azure Monitor voor SAP u kan helpen bij het beheren van de beschikbaarheid en prestaties van SAP-services.

Beveiliging

Veel beveiligingsmaatregelen worden gebruikt om de vertrouwelijkheid, integriteit en beschikbaarheid van een SAP-landschap te beschermen. Voor het beveiligen van gebruikerstoegang heeft SAP bijvoorbeeld een eigen UME (User Management Engine) voor het beheren van op rollen gebaseerde toegang en autorisatie binnen de SAP-toepassing en -databases. Zie SAP HANA-beveiliging: een overzicht voor meer informatie.

Voor data-at-rest bieden verschillende versleutelingsfuncties als volgt beveiliging:

• Naast de systeemeigen SAP HANA-versleutelingstechnologie kunt u een versleutelingsoplossing van een partner gebruiken die door de klant beheerde sleutels ondersteunt.

• Als u schijven van virtuele machines wilt versleutelen, kunt u functies gebruiken die worden beschreven in Het overzicht van schijfversleuteling.

• SAP Database-servers: Gebruik Transparent Data Encryption die wordt aangeboden door de DBMS-provider (bijvoorbeeld SAP HANA-systeemeigen versleutelingstechnologie) om uw gegevens en logboekbestanden te beveiligen en ervoor te zorgen dat de back-ups ook worden versleuteld.

• Gegevens in fysieke Azure-opslag (versleuteling aan serverzijde) worden automatisch at-rest versleuteld met een door Azure beheerde sleutel. U kunt ook een door de klant beheerde sleutel (CMK) kiezen in plaats van de door Azure beheerde sleutel.

• Zie Azure Disk Encryption voor Linux-VM's voor informatie over de ondersteuning van Azure Disk Encryption voor bepaalde Linux-distributies, versies en installatiekopieën.

Gebruik voor netwerkbeveiliging netwerkbeveiligingsgroepen (NSG's) en Azure Firewall of een virtueel netwerkapparaat als volgt:

• Gebruik NSG's om verkeer tussen subnetten en toepassings-/databaselagen te beveiligen en te beheren. Pas alleen NSG's toe op subnetten. NSG's die worden toegepast op zowel NIC als subnet, leiden vaak tot problemen tijdens het oplossen van problemen en moeten zelden als ooit worden gebruikt.

• Gebruik Azure Firewall of virtueel Azure-netwerkapparaat om de routering van verkeer van het virtuele hubnetwerk naar het virtuele spoke-netwerk waar uw SAP-toepassingen zich bevinden te inspecteren en te beheren en om de uitgaande internetverbinding te beheren.

Voor gebruikers en autorisatie implementeert u op rollen gebaseerd toegangsbeheer (RBAC) en resourcevergrendelingen als volgt:

• Volg het principe van minimale bevoegdheden, waarbij u RBAC gebruikt voor het toewijzen van beheerdersbevoegdheden bij Resources op IaaS-niveau die als host fungeren voor uw SAP-oplossing in Azure. Het fundamentele doel van RBAC is de scheiding en controle van taken voor uw gebruikers/groep. RBAC is ontworpen om alleen de hoeveelheid toegang te verlenen tot resources die nodig zijn om gebruikers in staat te stellen hun taken uit te voeren.

• Gebruik resourcevergrendelingen om onbedoelde of schadelijke wijzigingen te voorkomen. Resourcevergrendelingen helpen voorkomen dat beheerders kritieke Azure-resources verwijderen of wijzigen waar uw SAP-oplossing zich bevindt.

Meer aanbevelingen voor beveiliging vindt u in deze Microsoft- en SAP-artikelen.

Community's

Community's kunnen vragen beantwoorden en helpen om een succesvolle implementatie in te stellen. Houd rekening met de volgende community's:

• Ondersteuning voor De Azure-community

• SAP-community

• SAP op Stack Overflow

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

• Robert Biro | Senior Architect

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Meer informatie over de onderdeeltechnologieën:

• Wat is Azure ExpressRoute?
• Wat is Azure Bastion?
• Wat is Power BI?
• De SAP Business Warehouse-connector gebruiken in Power BI Desktop
• SAP-werkbelastingconfiguraties met Azure-beschikbaarheidszones
• Wat is de Azure Backup-service?
• Over siteherstel
• Wat is Azure Load Balancer?
• Verbinding maken naar SAP HANA-databases in Power BI
• Wat is Azure NetApp Files?
• Inleiding tot beheerde Azure-schijven
• Virtuele Linux-machines in Azure
• Installatie van SAP HANA op virtuele Azure-machines
• Wat is Azure Virtual Network?
• Netwerkbeveiligingsgroepen
• SAP HANA-herstel na noodgevallen met Azure NetApp Files

Verwante resources

Gerelateerde architecturen verkennen:

• Een Linux VM uitvoeren op Azure
• SAP BW/4HANA uitvoeren met virtuele Linux-machines in Azure
• SAP S/4HANA in Linux on Azure
• Handleiding voor SAP op Azure-architectuur