Configuraties en bewerkingen van SAP HANA-infrastructuur in Azure

Dit document bevat richtlijnen voor het configureren van de Azure-infrastructuur en SAP HANA-systemen die zijn geïmplementeerd op systeemeigen virtuele Azure-machines (VM's). Het document bevat ook configuratie-informatie voor SAP HANA uitschalen voor de M128s VM-SKU. Dit document is niet bedoeld ter vervanging van de sap-standaarddocumentatie, die de volgende inhoud bevat:

• SAP-beheerhandleiding
• SAP-installatiehandleidingen
• SAP-notities

Vereisten

Als u deze handleiding wilt gebruiken, hebt u basiskennis nodig van de volgende Azure-onderdelen:

• Virtuele Azure-machines
• Azure-netwerken en virtuele netwerken
• Azure Storage

Zie de sectie SAP on Azure azure-documentatie voor meer informatie over SAP NetWeaver en andere SAP-onderdelen in Azure.

Basisoverwegingen bij het instellen

In de volgende secties worden basisoverwegingen beschreven voor het implementeren van SAP HANA-systemen op Azure-VM's.

Verbinding maken virtuele Azure-machines maken

Zoals beschreven in de planningshandleiding voor virtuele Azure-machines,zijn er twee basismethoden om verbinding te maken met azure-VM's:

• Verbinding maken via internet en openbare eindpunten op een virtuele jump-VM of op de virtuele SAP HANA.
• Verbinding maken via een VPN of Azure ExpressRoute.

Site-naar-site-connectiviteit via VPN of ExpressRoute is nodig voor productiescenario's. Dit type verbinding is ook nodig voor niet-productiescenario's die worden gebruikt in productiescenario's waarin SAP-software wordt gebruikt. In de volgende afbeelding ziet u een voorbeeld van connectiviteit tussen verschillende plaatsen:

Azure VM-typen kiezen

De Azure VM-typen die kunnen worden gebruikt voor productiescenario's worden vermeld in de SAP-documentatie voor IAAS. Voor niet-productiescenario's is een grotere verscheidenheid aan native Azure-VM-typen beschikbaar.

Implementeer de VM's in Azure met behulp van:

• De Azure-portal.
• Azure PowerShell cmdlets.
• De Azure CLI.

U kunt ook een volledig geïnstalleerd SAP HANA op de Azure VM-services implementeren via het SAP Cloud-platform. Het installatieproces wordt beschreven in SAP S/4HANA of BW/4HANA implementeren in Azure of met de automatisering die is uitgebracht op GitHub.

Storage configuratie voor SAP HANA

Als u opslagconfiguraties en opslagtypen wilt gebruiken met SAP HANA in Azure, leest u het document SAP HANA azure virtual machine storage configurations (Opslagconfiguraties voor virtuele Azure-machines)

Virtuele Azure-netwerken instellen

Wanneer u site-naar-site-connectiviteit hebt met Azure via VPN of ExpressRoute, moet u ten minste één virtueel Azure-netwerk hebben dat via een virtuele gateway is verbonden met het VPN- of ExpressRoute-circuit. In eenvoudige implementaties kan de virtuele gateway worden geïmplementeerd in een subnet van het virtuele Azure-netwerk (VNet) dat de SAP HANA-exemplaren host. Als u SAP HANA, maakt u twee extra subnetten binnen het virtuele Azure-netwerk. Eén subnet host de VM's om de SAP HANA uit te voeren. In het andere subnet worden Jumpbox- of beheer-VM's uitgevoerd om SAP HANA Studio, andere beheersoftware of uw toepassingssoftware te hosten.

Wanneer u de VM's installeert om deze SAP HANA, hebben de VM's het volgende nodig:

• Er zijn twee virtuele NIC's geïnstalleerd: één NIC om verbinding te maken met het beheersubnet en één NIC om vanuit het on-premises netwerk of andere netwerken verbinding te maken met het SAP HANA-exemplaar in de Azure-VM.
• Statische privé-IP-adressen die zijn geïmplementeerd voor beide virtuele NIC's.

Voor implementaties die duurzaam zijn, moet u echter een virtuele datacenternetwerkarchitectuur maken in Azure. Deze architectuur raadt de scheiding aan van de Azure-VNet Gateway die verbinding maakt met on-premises in een afzonderlijk Azure VNet. Dit afzonderlijke VNet moet als host dienen voor al het verkeer dat naar on-premises of internet gaat. Met deze aanpak kunt u software implementeren voor het controleren en registreren van verkeer dat het virtuele datacenter in Azure binnenkomt in dit afzonderlijke hub-VNet. U hebt dus één VNet dat alle software en configuraties host die betrekking hebben op in- en uitgaand verkeer naar uw Azure-implementatie.

De artikelen Azure Virtual Datacenter: A Network Perspective en Azure Virtual Datacenter en Enterprise Control Plane geven meer informatie over de benadering van het virtuele datacenter en het bijbehorende Azure VNet-ontwerp.

Zie IP-adrestypen en toewijzingsmethoden in Azure voor een overzicht van de verschillende methoden voor het toewijzen van IP-adressen.

Voor VM's SAP HANA, moet u werken met toegewezen statische IP-adressen. Reden is dat sommige configuratiekenmerken voor HANA-referentie-IP-adressen.

Azure-netwerkbeveiligingsgroepen (NSG's) worden gebruikt om verkeer te sturen dat wordt doorgeleid naar het SAP HANA-exemplaar of de jumpbox. De NSG's en uiteindelijk toepassingsbeveiligingsgroepen worden gekoppeld aan SAP HANA subnet en het beheersubnet.

In de volgende afbeelding ziet u een overzicht van een ruw implementatieschema voor SAP HANA een hub en spoke-VNet-architectuur:

Als u SAP HANA wilt implementeren in Azure zonder een site-naar-site-verbinding, wilt u het SAP HANA-exemplaar nog steeds afschermen van het openbare internet en deze verbergen achter een doorgestuurde proxy. In dit eenvoudige scenario is de implementatie afhankelijk van de ingebouwde DNS-services van Azure om hostnamen om te draaien. In een complexere implementatie waarbij openbare IP-adressen worden gebruikt, zijn ingebouwde DNS-services van Azure met name belangrijk. Gebruik Azure NSG's en Azure N NV's om de routering van internet naar uw Azure VNet-architectuur in Azure te controleren. In de volgende afbeelding ziet u een ruw schema voor het implementeren van SAP HANA zonder een site-naar-site-verbinding in een hub-and-spoke-VNet-architectuur:

Een andere beschrijving van het gebruik van Azure NNA's voor het controleren en controleren van de toegang vanaf internet zonder de hub en spoke VNet-architectuur vindt u in het artikel Deploy highly available network virtual appliances (Virtuele netwerkapparaten met hoge beschikbare netwerkapparaten implementeren).

Azure-infrastructuur configureren SAP HANA uitschalen

Als u wilt weten welke Azure-VM-typen zijn gecertificeerd voor uitschalen van OLAP of uitschalen van S/4HANA, raadpleegt u de hardwaremap SAP HANA azure-hardware. Een vinkje in de kolom Clustering geeft ondersteuning voor uitschalen aan. Toepassingstype geeft aan of uitschalen van OLAP of S/4HANA-uitschalen wordt ondersteund. Voor meer informatie over knooppunten die zijn gecertificeerd in uitschalen voor elk van de VM's, controleert u de details van de vermeldingen in de specifieke VM-SKU die wordt vermeld in de hardwaremap SAP HANA VM.

De minimale versie van het besturingssysteem voor het implementeren van scale-out configuraties in Azure-VM's, controleert u de details van de vermeldingen in de specifieke VM-SKU die wordt vermeld in de hardwaremap SAP HANA VM. Van een OLAP-uitschaalconfiguratie met n-knooppunt fungeert één knooppunt als hoofd-knooppunt. De andere knooppunten tot de limiet van de certificering fungeren als werkknooppunt. Extra stand-byknooppunten tellen niet mee voor het aantal gecertificeerde knooppunten

Voor /hana/shared raden we ook het gebruik van Azure NetApp Files.

Een typisch basisontwerp voor één knooppunt in een scale-out configuratie ziet er als volgende uit:

De basisconfiguratie van een VM-knooppunt voor SAP HANA uitschalen ziet er als volgende uit:

• Voor /hana/shared gebruikt u de native NFS-service die wordt geleverd via Azure NetApp Files.
• Alle andere schijfvolumes worden niet gedeeld tussen de verschillende knooppunten en zijn niet gebaseerd op NFS. Installatieconfiguraties en -stappen voor scale-out HANA-installaties met niet-gedeelde /hana/data en /hana/log worden verderop in dit document be gegeven. Raadpleeg voor HANA gecertificeerde opslag die kan worden gebruikt, het artikel SAP HANA azure virtual machine storage configurations (Opslagconfiguraties voor virtuele Azure-machines).

Als u de grootte van de volumes of schijven wilt wijzigen, moet u het document SAP HANA TDI Storage Requirementscontroleren op de vereiste grootte, afhankelijk van het aantal werkknooppunten. In het document wordt een formule uitgebracht die u moet toepassen om de vereiste capaciteit van het volume op te halen

De andere ontwerpcriteria die worden weergegeven in de grafische weergave van de configuratie van één knooppunt voor een scale-out SAP HANA-VM is het VNet, of beter nog, de subnetconfiguratie. SAP raadt ten zeerste aan het client-/toepassingsverkeer te scheiden van de communicatie tussen de HANA-knooppunten. Zoals u in de afbeeldingen kunt zien, wordt dit doel bereikt door twee verschillende vNIC's aan de VM te koppelen. Beide vNIC's zijn in verschillende subnetten, hebben twee verschillende IP-adressen. Vervolgens controleert u de verkeersstroom met routeringsregels met behulp van NSG's of door de gebruiker gedefinieerde routes.

Met name in Azure zijn er geen middelen en methoden om de kwaliteit van de service en quota op specifieke vNIC's af te dwingen. Als gevolg hiervan biedt de scheiding van client-/toepassingscommunicatie en intra-knooppuntcommunicatie geen mogelijkheden om prioriteit te geven aan de ene verkeersstroom boven de andere. In plaats daarvan blijft de scheiding een maat voor de beveiliging bij het afschermen van de communicatie tussen knooppunt en de scale-out configuraties.

Vanuit het oogpunt van netwerken ziet de minimaal vereiste netwerkarchitectuur er als volgende uit:

Uitschalen SAP HANA Azure installeren

Als u een scale-out SAP-configuratie installeert, moet u de volgende ruwe stappen uitvoeren:

• Nieuwe Azure VNet-infrastructuur implementeren of aanpassen
• De nieuwe VM's implementeren met behulp van Azure Managed Premium Storage, Ultra Disk Volumes en/of NFS-volumes op basis van ANF
• • Pas netwerkroutering aan om ervoor te zorgen dat bijvoorbeeld communicatie tussen knooppunt tussen VM's niet wordt gerouteerd via een NVA.
• Installeer het SAP HANA hoofd-knooppunt.
• Configuratieparameters van het SAP HANA hoofd-knooppunt aanpassen
• Doorgaan met de installatie van de SAP HANA werkknooppunten

Installatie van SAP HANA in scale-out configuratie

Wanneer uw Azure VM-infrastructuur wordt geïmplementeerd en alle andere voorbereidingen zijn uitgevoerd, moet u de SAP HANA scale-out configuraties installeren in deze stappen:

• Installeer het SAP HANA hoofd-knooppunt volgens de documentatie van SAP
• Als u Azure Premium Storage of Ultra Disk Storage gebruikt met niet-gedeelde schijven van /hana/data en /hana/log, moet u het global.ini-bestand wijzigen en de parameter 'basepath_shared = nee' toevoegen aan het global.ini-bestand. Met deze parameter SAP HANA worden uitgevoerd in scale-out zonder 'gedeelde' /hana/data en /hana/log-volumes tussen de knooppunten. Details worden beschreven in SAP-notitie #2080991. Als u NFS-volumes gebruikt op basis van ANF voor /hana/data en /hana/log, hoeft u deze wijziging niet aan te brengen
• Na de uiteindelijke wijziging in de parameter global.ini start u de SAP HANA op
• Voeg extra werkknooppunten toe. Zie ook https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.00/en-US/0d9fe701e2214e98ad4f8721f6558c34.html . Geef het interne netwerk voor SAP HANA communicatie tussen knooppunt tijdens de installatie of daarna met behulp van bijvoorbeeld de lokale hdblcm. Zie ook SAP Note #2183363 voor meer 2183363.

Meer informatie over het instellen van een SAP HANA-uitschaalsysteem met stand-by-knooppunt in SUSE Linux wordt gedetailleerd beschreven in Deploy a SAP HANA scale-out system with standby node on Azure VMs by using Azure NetApp Files on SUSE Linux Enterprise Server (Een SAP HANA-scale-outsysteemimplementeren met stand-by-knooppunt op virtuele Azure-VM's met behulp van Azure NetApp Files op SUSE Linux Enterprise Server ). Equivalente documentatie voor Red Hat vindt u in het artikel Deploy a SAP HANA scale-out system with standby nodeon Azure VMs by using Azure NetApp Files on Red Hat Enterprise Linux .

SAP HANA Dynamic Tiering 2.0 for Azure virtual machines (Dynamische opslaglagen 2.0 voor virtuele Azure-machines)

Naast de SAP HANA-certificeringen op VM's uit de Azure M-serie wordt SAP HANA Dynamic Tiering 2.0 ook ondersteund op Microsoft Azure (zie de koppelingen naar de documentatie voor dynamische lagen van SAP HANA verderop). Hoewel er geen verschil is in het installeren of gebruiken van het product, bijvoorbeeld via SAP HANA Cockpit in een virtuele Azure-machine, zijn er enkele belangrijke items die verplicht zijn voor officiële ondersteuning in Azure. Deze belangrijke punten worden hieronder beschreven. In het hele artikel wordt de afkorting 'DT 2.0' gebruikt in plaats van de volledige naam Dynamische laag 2.0.

SAP HANA Dynamische laag 2.0 wordt niet ondersteund door SAP BW of S4HANA. De belangrijkste use cases op dit moment zijn native HANA-toepassingen.

Overzicht

In de onderstaande afbeelding ziet u een overzicht van DT 2.0-ondersteuning op Microsoft Azure. Er is een reeks verplichte vereisten die moeten worden gevolgd om te voldoen aan de officiële certificering:

• DT 2.0 moet worden geïnstalleerd op een toegewezen Azure-VM. Het kan niet worden uitgevoerd op dezelfde VM waarop SAP HANA wordt uitgevoerd
• SAP HANA VM's en DT 2.0-VM's moeten worden geïmplementeerd in hetzelfde Azure VNet
• De SAP HANA en DT 2.0-VM's moeten worden geïmplementeerd met versneld netwerken van Azure ingeschakeld
• Storage type voor de DT 2.0-VM's moet Azure-Premium Storage
• Er moeten meerdere Azure-schijven worden gekoppeld aan de DT 2.0-VM
• U moet een software-raid/-striped volume maken (via lvm of m²m) met behulp van striping over de Azure-schijven

Meer informatie wordt uitgelegd in de volgende secties.

Toegewezen Azure-VM voor SAP HANA DT 2.0

Op Azure IaaS wordt DT 2.0 alleen ondersteund op een toegewezen VM. Het is niet toegestaan om DT 2.0 uit te voeren op dezelfde Azure-VM waarop het HANA-exemplaar wordt uitgevoerd. In eerste instantie kunnen twee VM-typen worden gebruikt om SAP HANA DT 2.0:

• M64-32 ms
• E32sv3

Zie Azure VM-grootten - geheugen voor meer informatie over de beschrijving van het VM-type

Gezien het basisprincipe van DT 2.0, dat gaat over het offloaden van 'warme' gegevens om kosten te besparen, is het zinvol om bijbehorende VM-grootten te gebruiken. Er is echter geen strikte regel met betrekking tot de mogelijke combinaties. Dit is afhankelijk van de specifieke workload van de klant.

Aanbevolen configuraties zijn:

Alle combinaties van SAP HANA-gecertificeerde VM's uit de M-serie met ondersteunde DT 2.0-VM's (M64-32 ms en E32sv3) zijn mogelijk.

Azure-netwerken SAP HANA DT 2.0

Voor het installeren van DT 2.0 op een toegewezen VM is netwerkdoorvoer tussen de DT 2.0-VM en de SAP HANA-VM van minimaal 10 Gb vereist. Daarom is het verplicht om alle VM's binnen hetzelfde Azure-Vnet te plaatsen en versneld netwerken van Azure in teschakelen.

Zie aanvullende informatie over versneld netwerken van Azure Een Azure-VM met versneld netwerken maken met behulp van Azure CLI

VM Storage voor SAP HANA DT 2.0

Volgens de richtlijnen van DT 2.0 best practice moet de schijf-I/O-doorvoer minimaal 50 MB per seconde per fysieke kern zijn. Bekijk de specificatie voor de twee Azure-VM-typen, die worden ondersteund voor DT 2.0. De maximale doorvoerlimiet voor schijf-I/O voor de VM ziet er als volgende uit:

• E32sv3: 768 MB/sec (niet-gecached), wat een verhouding van 48 MB per seconde per fysieke kern betekent
• M64-32 ms: 1000 MB per seconde (niet-gecached), wat een verhouding van 62,5 MB/sec per fysieke kern betekent

U moet meerdere Azure-schijven koppelen aan de DT 2.0-VM en een software-raid (striping) maken op besturingssysteemniveau om de maximale limiet voor schijfdoorvoer per VM te bereiken. Eén Azure-schijf kan in dit opzicht niet de doorvoer leveren om de maximale VM-limiet te bereiken. Azure Premium-opslag is verplicht om DT 2.0 uit te voeren.

• Meer informatie over beschikbare Azure-schijftypen vindt u op de pagina Een schijftype selecteren voor Azure IaaS-VM's - beheerde schijven
• Meer informatie over het maken van software-raid via mpagem vindt u op de pagina Software RAID configureren op een Linux-VM
• Meer informatie over het configureren van LVM voor het maken van een striped volume voor maximale doorvoer vindt u op de pagina LVM configureren op een virtuele machine met Linux

Afhankelijk van de groottevereisten zijn er verschillende opties om de maximale doorvoer van een VM te bereiken. Hier zijn mogelijke schijfconfiguraties voor gegevensvolumes voor elk DT 2.0 VM-type om de bovengrens voor de VM-doorvoer te bereiken. De VM E32sv3 moet worden beschouwd als een toegangsniveau voor kleinere workloads. Als blijkt dat de VM niet snel genoeg is, kan het nodig zijn om de VM te veranderen in M64-32 ms. Omdat de virtuele M64-32ms-VM veel geheugen heeft, bereikt de I/O-belasting mogelijk niet de limiet, met name voor leesintensieve werkbelastingen. Daarom is het mogelijk dat minder schijven in de stripe-set voldoende zijn, afhankelijk van de specifieke workload van de klant. Maar om aan de veilige kant te staan, zijn de onderstaande schijfconfiguraties gekozen om de maximale doorvoer te garanderen:

Met name als de workload lees-intensief is, kan dit de I/O-prestaties verbeteren door azure-hostcache 'alleen-lezen' in te zetten, zoals aanbevolen voor de gegevensvolumes van databasesoftware. Voor het transactielogboek moet de schijfcache van de Azure-host 'geen' zijn.

Met betrekking tot de grootte van het logboekvolume is een aanbevolen beginpunt een heuristiek van 15% van de gegevensgrootte. Het maken van het logboekvolume kan worden uitgevoerd met behulp van verschillende Azure-schijftypen, afhankelijk van de kosten- en doorvoervereisten. Voor het logboekvolume is een hoge I/O-doorvoer vereist. In het geval van het gebruik van het VM-type M64-32ms is het verplicht om in te Write Accelerator. Azure Write Accelerator biedt een optimale schrijflatentie voor de schijf voor het transactielogboek (alleen beschikbaar voor de M-serie). Er zijn enkele items die u moet overwegen, zoals het maximum aantal schijven per VM-type. Meer informatie over Write Accelerator vindt u op de pagina Azure Write Accelerator

Hier zijn enkele voorbeelden van het aanpassen van de omvang van het logboekvolume:

Net als SAP HANA uitschalen, moet de map /hana/shared worden gedeeld tussen de SAP HANA-VM en de DT 2.0-VM. Dezelfde architectuur als voor SAP HANA uitschalen met behulp van toegewezen VM's, die fungeren als een NFS-server met hoge beschikbare gegevens. Om een gedeeld back-upvolume te bieden, kan het identieke ontwerp worden gebruikt. Maar het is aan de klant of hoge capaciteit nodig is of dat het voldoende is om alleen een toegewezen VM met voldoende opslagcapaciteit te gebruiken om te fungeren als een back-upserver.

Koppelingen naar documentatie voor DT 2.0

• SAP HANA installatie- en updatehandleiding voor dynamische opslaglagen
• SAP HANA zelfstudies en resources voor dynamische opslaglagen
• SAP HANA PoC voor dynamische lagen
• SAP HANA 2.0 SPS 02 dynamische lagen verbeteren

Bewerkingen voor het implementeren van SAP HANA op Virtuele Azure-VM's

In de volgende secties worden enkele bewerkingen beschreven die betrekking hebben op het implementeren van SAP HANA-systemen op Azure-VM's.

Back-up- en herstelbewerkingen op virtuele Azure-VM's

In de volgende documenten wordt beschreven hoe u een back-up kunt maken van uw SAP HANA implementatie:

• Overzicht van back-ups van SAP HANA
• SAP HANA back-up op bestandsniveau maken
• SAP HANA storage snapshot benchmark (benchmark voor opslagmomentopnamen)

VM's met een SAP HANA

Een belangrijke functie van de openbare Azure-cloud is dat er alleen kosten in rekening worden gebracht voor uw rekenminuten. Wanneer u bijvoorbeeld een VM met SAP HANA, wordt u alleen gefactureerd voor de opslagkosten gedurende die periode. Een andere functie is beschikbaar wanneer u statische IP-adressen opgeeft voor uw VM's in uw eerste implementatie. Wanneer u een virtuele SAP HANA opnieuw opstart, wordt de VM opnieuw opgestart met de voorgaande IP-adressen.

SAProprogramm gebruiken voor externe SAP-ondersteuning

Als u een site-naar-site-verbinding hebt tussen uw on-premises locaties en Azure en u SAP-onderdelen gebruikt, bent u waarschijnlijk al met SAProprogramm. In dit geval voltooit u de volgende items voor externe ondersteuning:

• Behoud het privé- en statische IP-adres van de VM die als host SAP HANA in de SAPropro-configuratie.
• Configureer de NSG van het subnet dat als host voor de HANA-VM wordt gebruikt om verkeer via TCP/IP-poort 3299 toe te staan.

Als u via internet verbinding maakt met Azure en u geen SAP-router hebt voor de VM met SAP HANA, moet u het onderdeel installeren. Installeer SAProloft in een afzonderlijke virtuele machine in het beheersubnet. In de volgende afbeelding ziet u een ruw schema voor het implementeren van SAP HANA zonder site-naar-site-verbinding en met SAProprogramm:

Zorg ervoor dat u SAProprogramm installeert in een afzonderlijke VM en niet in uw Jumpbox-VM. De afzonderlijke VM moet een statisch IP-adres hebben. Neem contact op met SAP voor een IP-adres om uw SAPropunt te verbinden met de SAProprop die wordt gehost door SAP. (De SAProloft die wordt gehost door SAP is het equivalent van het SAProloft-exemplaar dat u op uw VM installeert.) Gebruik het IP-adres van SAP om uw SAPro exemplaren te configureren. In de configuratie-instellingen is TCP-poort 3299 de enige benodigde poort.

Zie de SAP-documentatievoor meer informatie over het instellen en onderhouden van externe ondersteuningsverbindingen via SAProcentrum.

Hoge beschikbaarheid met SAP HANA op native Azure-VM's

Als u een SUSE Linux Enterprise Server of Red Hat gebruikt, kunt u een Pacemaker-cluster met STONITH-apparaten tot stand laten komen. U kunt de apparaten gebruiken om een SAP HANA in te stellen die gebruikmaakt van synchrone replicatie met HANA-systeemreplicatie en automatische failover. Voor meer informatie die wordt vermeld in de sectie Volgende stappen.

Volgende stappen

Vertrouwd raken met de vermelde artikelen

• Configuraties van SAP HANA in virtuele Azure-machineopslag
• Implementeer een SAP HANA scale-out systeem met stand-by-knooppunt op Virtuele Azure-Azure NetApp Files op SUSE Linux Enterprise Server
• Implementeer een SAP HANA scale-out systeem met stand-by-knooppunt op Virtuele Azure-Azure NetApp Files op Red Hat Enterprise Linux
• Hoge beschikbaarheid van SAP HANA in Azure-VM's op SUSE Linux Enterprise Server
• Hoge beschikbaarheid van SAP HANA in Azure-VM's op Red Hat Enterprise Linux