SQL Server Azure Virtual Machines DBMS-implementatie voor SAP NetWeaver

Dit document bevat verschillende gebieden die u kunt overwegen bij het implementeren SQL Server sap-workload in Azure IaaS. Als voorwaarde voor dit document moet u het document Considerations for Azure Virtual Machines DBMS deployment for SAP workload (Overwegingen voor de implementatie van Azure Virtual Machines DBMS voor SAP-workload) en andere handleidingen in de documentatie voor SAP-workload in Azure hebben gelezen.

Over het algemeen kunt u overwegen om de meest recente versies SQL Server sap-workload uit te voeren in Azure IaaS. De nieuwste SQL Server bieden een betere integratie in sommige Azure-services en -functionaliteit. Of wijzigingen aanbrengen die bewerkingen optimaliseren in een Azure IaaS-infrastructuur.

Het is raadzaam om het artikel Wat is er SQL Server in Azure Virtual Machines (Windows) te lezen voordat u doorgaat.

In de volgende secties worden delen van de documentatie onder de bovenstaande koppeling geaggregeerd en vermeld. Specifieke informatie over SAP wordt ook vermeld en sommige concepten worden gedetailleerder beschreven. Het wordt echter ten zeerste aanbevolen om eerst de bovenstaande documentatie te lezen voordat SQL Server specifieke documentatie leest.

Er zijn enkele SQL Server informatie in IaaS die u moet kennen voordat u doorgaat:

• SQL versieondersteuning: voor SAP-klanten wordt SQL Server 2008 R2 en hoger ondersteund op Microsoft Azure virtuele machine. Eerdere edities worden niet ondersteund. Bekijk deze algemene ondersteuningsverklaring voor meer informatie. Over het algemeen SQL Server 2008 ook ondersteund door Microsoft. Vanwege de aanzienlijke functionaliteit voor SAP, die is geïntroduceerd in SQL Server 2008 R2, is SQL Server 2008 R2 de minimale release voor SAP. Over het algemeen kunt u overwegen om de meest recente versies SQL Server sap-workload uit te voeren in Azure IaaS. De nieuwste SQL Server bieden een betere integratie in sommige Azure-services en -functionaliteit. Of wijzigingen aanbrengen die bewerkingen optimaliseren in een Azure IaaS-infrastructuur. Daarom is het document beperkt tot SQL Server 2016 en SQL Server 2017.
• SQL prestaties: Microsoft Azure gehoste Virtual Machines presteren goed in vergelijking met andere aanbiedingen voor openbare cloudvirtualisatie, maar de afzonderlijke resultaten kunnen variëren. Raadpleeg het artikel Best practices voor prestaties voor SQL Server in Azure Virtual Machines.
• Met behulp van Azure Marketplace: de snelste manier om een nieuwe virtuele Microsoft Azure te implementeren, is het gebruik van een afbeelding van de Azure Marketplace. Er zijn afbeeldingen in de Azure Marketplace, die de meest recente SQL Server bevatten. De installatie van SQL Server al is geïnstalleerd, kunnen niet onmiddellijk worden gebruikt voor SAP NetWeaver-toepassingen. De reden hiervoor is dat de standaardinstelling SQL Server de installatie van de collatie wordt geïnstalleerd in die installatie, en niet de collatie die is vereist voor SAP NetWeaver-systemen. Als u dergelijke afbeeldingen wilt gebruiken, controleert u de stappen die worden beschreven in het hoofdstuk Using a SQL Server image out of the Microsoft Azure Marketplace.
• SQL Server ondersteuning voor meerdere exemplaren binnen één Azure-VM: deze implementatiemethode wordt ondersteund. Let echter op resourcebeperkingen, met name met betrekking tot de netwerk- en opslagbandbreedte van het VM-type dat u gebruikt. Gedetailleerde informatie is beschikbaar in het artikel Grootten voor virtuele machines in Azure. Deze quotumbeperkingen verhinderen mogelijk dat u dezelfde architectuur met meerdere exemplaren implementeert als u on-premises kunt implementeren. Met het oog op de configuratie en interferentie van het delen van de resources die beschikbaar zijn binnen één VM, moet rekening worden gehouden met dezelfde overwegingen als on-premises.
• Meerdere SAP-databases in één SQL Server in één VM: zoals hierboven worden configuraties als deze ondersteund. Overwegingen voor meerdere SAP-databases die de gedeelde resources van één SQL Server delen, zijn hetzelfde als voor on-premises implementaties. Houd ook rekening met andere limieten, zoals het aantal schijven dat kan worden gekoppeld aan een specifiek VM-type. Of netwerk- en opslagquotumlimieten van specifieke VM-typen als gedetailleerde grootten voor virtuele machines in Azure.

Aanbevelingen VM-/VHD-structuur voor SAP-gerelateerde SQL Server implementaties

In overeenstemming met de algemene beschrijving, Besturingssysteem, SQL Server uitvoerbare bestanden, en in het geval van SAP 2-laag-systemen, moeten de UITVOERBARE SAP-bestanden zich bevinden of afzonderlijke Azure-schijven installeren. Normaal gesproken worden de meeste SQL Server systeemdatabases niet op hoog niveau gebruikt door SAP NetWeaver-workload. De systeemdatabases van SQL Server (master, msdb en model) moeten zich echter samen met de andere SQL Server op een afzonderlijke Azure-schijf. SQL Server tempdb moet zich bevinden op de niet-geperisisteerde D:\ station of op een afzonderlijke schijf.

• Met alle sap-gecertificeerde VM-typen (zie SAP Note 1928533), kunnen behalve VM's uit de A-serie, tempdb-gegevens en logboekbestanden worden geplaatst op de niet-persistente D:\ Station.
• Voor oudere SQL Server,waarbij SQL Server tempdb standaard met één gegevensbestand installeert, wordt het aanbevolen om meerdere tempdb-gegevensbestanden te gebruiken. Let op D:\ schijfvolumes verschillen op basis van het VM-type. Voor de exacte grootte van de D:\ station van de verschillende VM's, raadpleegt u het artikel Grootten voor Windows virtuele machines in Azure.

Met deze configuraties kan tempdb meer ruimte en belangrijkere IOPS- en opslagbandbreedte gebruiken dan het systeemstation kan bieden. De niet-persistente D:\ station biedt ook een betere I/O-latentie en doorvoer (met uitzondering van VM's uit de A-serie). Als u de juiste tempdb-grootte wilt bepalen, kunt u de tempdb-grootten op bestaande systemen controleren.

Een VM-configuratie die SQL Server met een SAP-database en waar tempdb-gegevens en tempdb-logboekbestanden op de D:\ worden geplaatst station ziet er als volgende uit:

In het bovenstaande diagram ziet u een eenvoudig geval. Zoals beschreven in het artikel Overwegingen voor Azure Virtual Machines DBMS-implementatie voor SAP-workload,is het Azure-opslagtype, het aantal en de grootte van schijven afhankelijk van verschillende factoren. Maar over het algemeen raden we het volgende aan:

• Gebruik één groot volume, dat de SQL Server bevat. De reden achter deze configuratie is dat er in werkelijkheid talloze SAP-databases zijn met verschillende databasebestanden van verschillende grootte met verschillende I/O-workloads.
• Gebruik het D:\station voor tempdb, zolang de prestaties maar goed genoeg zijn. Als de algehele werkbelasting beperkt is in de prestaties door tempdb zich op de D:\ bevindt het station dat u mogelijk moet overwegen om tempdb te verplaatsen naar afzonderlijke Azure Premium Storage- of Ultra Disk-schijven, zoals aanbevolen in dit artikel.

Speciaal voor VM's uit de M-serie

Voor azure M-Series VM's kan de latentie bij het schrijven naar het transactielogboek worden verminderd door factoren, vergeleken met de prestaties van Azure Premium Storage bij het gebruik van Azure Write Accelerator. Daarom moet u Azure-Write Accelerator voor de VHD('s) die het volume vormen voor het SQL Server transactielogboek. Details kunnen worden gelezen in het document Write Accelerator.

De schijven opmaken

Voor SQL Server moet de NTFS-blokgrootte voor schijven met SQL Server en logboekbestanden 64 kB zijn. U hoeft de D:\ niet op te maken Station. Dit station wordt geleverd vooraf opgemaakt.

Om ervoor te zorgen dat het herstellen of maken van databases de gegevensbestanden niet initialiseert door de inhoud van de bestanden op nul te zetten, moet u ervoor zorgen dat de gebruikerscontext waarin de SQL Server-service wordt uitgevoerd, een bepaalde machtiging heeft. Meestal hebben gebruikers in Windows beheerdersgroep deze machtigingen. Als de SQL Server-service wordt uitgevoerd in de gebruikerscontext van niet-Windows Administrator-gebruiker, moet u aan die gebruiker de gebruikersrecht volumeonderhoudstaken uitvoeren toewijzen. Zie de details in dit Microsoft Knowledge Base Artikel: https://support.microsoft.com/kb/2574695

Impact van databasecompressie

In configuraties waarbij I/O-bandbreedte een beperkende factor kan worden, kan elke meting, die IOPS vermindert, helpen om de workload uit te rekken die kan worden uitgevoerd in een IaaS-scenario zoals Azure. Daarom wordt, als dit nog niet is gedaan, SQL Server DOOR SAP en Microsoft aanbevolen voordat u een bestaande SAP-database uploadt naar Azure.

De aanbeveling om databasecompressie uit te voeren voordat u naar Azure uploadt, heeft twee redenen:

• De hoeveelheid gegevens die moet worden geüpload, is lager.
• De duur van de compressie-uitvoering is korter, ervan uitgaande dat er sterkere hardware met meer CPU's of een hogere I/O-bandbreedte of minder I/O-latentie on-premises kan worden gebruikt.
• Kleinere databasegrootten kunnen leiden tot lagere kosten voor schijftoewijzing

Databasecompressie werkt net zo goed in een Azure-Virtual Machines als on-premises. Raadpleeg het artikel Improved SAP compression tool MSSCOMPRESS (Verbeterde SAP-compressietool MSSCOMPRESS)voor meer informatie over het comprimeren van bestaande SAP NetWeaver-SQL Server databases.

SQL Server 2014 en recenter : Databasebestanden rechtstreeks opslaan op Azure Blob Storage

SQL Server 2014 en latere releases bestaat de mogelijkheid om databasebestanden rechtstreeks op te slaan in Azure Blob Store zonder de 'wrapper' van een VHD eromheen. Met name bij het gebruik van Standard Azure Storage of kleinere VM-typen maakt dit type implementatie scenario's mogelijk waarin u de limieten van IOPS kunt overschrijden die worden afgedwongen door een beperkt aantal schijven dat kan worden bevestigd aan enkele kleinere VM-typen. Deze implementatie werkt voor gebruikersdatabases, maar niet voor systeemdatabases van SQL Server. Het werkt ook voor gegevens en logboekbestanden van SQL Server. Als u een SAP SQL Server-database op deze manier wilt implementeren in plaats van deze in VHD's te verpakken, moet u rekening houden met het volgende:

• Het Storage account moet zich in dezelfde Azure-regio als het account dat wordt gebruikt om de VM te implementeren waarin SQL Server wordt uitgevoerd.
• Overwegingen die eerder zijn vermeld met betrekking tot de distributie van VHD's over verschillende Azure Storage Accounts zijn ook van toepassing op deze implementatiemethode. Betekent dat het aantal I/O-bewerkingen wordt geteld op de limieten van Azure Storage account.
• In plaats van rekening te houden met het I/O-quotum voor opslag van de VM, wordt het verkeer op opslagblobs dat de SQL Server-gegevens en logboekbestanden vertegenwoordigt, in rekening gehouden met de netwerkbandbreedte van de VM van het specifieke VM-type. Raadpleeg voor netwerk- en opslagbandbreedte van een bepaald VM-type het artikel Grootten voor Windows virtuele machines in Azure.
• Als gevolg van het pushen van bestands-I/O via het netwerkquotum, is het opslagquotum grotendeels vastgelopen en wordt de totale bandbreedte van de VM slechts gedeeltelijk gebruikt.
• De prestatiedoelen voor IOPS- en I/O-doorvoer die Azure Premium Storage voor de verschillende schijfgrootten heeft, zijn niet meer van toepassing. Zelfs als de blobs die u hebt gemaakt zich in Azure Premium Storage. De doelen worden beschreven in het artikel High performance Premium Storage beheerde schijven voor VM's. Als gevolg van het rechtstreeks plaatsen van SQL Server-gegevensbestanden en logboekbestanden in blobs die zijn opgeslagen in Azure Premium Storage, kunnen de prestatiekenmerken verschillen in vergelijking met VHD's in Azure Premium Storage.
• Op host gebaseerde caching als beschikbaar voor Azure Premium Storage-schijven is niet beschikbaar wanneer u SQL Server rechtstreeks in Azure-blobs plaatst.
• Op VM's uit de M-serie kan Azure Write Accelerator niet worden gebruikt voor het ondersteunen van schrijf schrijfgegevens in SQL Server transactielogboekbestand.

Meer informatie over deze functionaliteit vindt u in het artikel SQL Server gegevensbestanden in Microsoft Azure

Aanbeveling voor productiesystemen is om deze configuratie te vermijden en in plaats daarvan de plaatsing van SQL Server-gegevens en logboekbestanden in Azure Premium Storage-VHD's te kiezen in plaats van rechtstreeks op Azure-blobs.

SQL Server buffergroepextensie van 2014

SQL Server 2014 is een nieuwe functie geïntroduceerd, die buffergroepextensie wordt genoemd. Deze functionaliteit breidt de buffergroep van SQL Server uit, die in het geheugen wordt opgeslagen met een cache op het tweede niveau die wordt back-by door lokale SD's van een server of VM. Met de buffergroepextensie kunt u een grotere werkset met gegevens 'in het geheugen' houden. Vergeleken met toegang tot Azure Standard Storage de toegang tot de extensie van de buffergroep, die wordt opgeslagen op lokale SD's van een Azure-VM, veel factoren sneller. Als u de buffergroepextensie vergelijkt met Azure Premium Storage Read Cache, zoals aanbevolen voor SQL Server-gegevensbestanden, worden er geen aanzienlijke voordelen verwacht voor buffergroepextensies. De reden hiervoor is dat beide caches (SQL Server buffergroepextensie en Premium Storage Leescache) gebruikmaken van de lokale schijven van het Azure-reken knooppunt.

Ervaringen die in de tussentijd zijn opgedaan met SQL Server buffergroepextensie met SAP-workload is gemengd en biedt nog steeds geen duidelijke aanbevelingen voor het gebruik ervan in alle gevallen. Het ideale geval is dat de werkset die de SAP-toepassing nodig heeft, in het hoofdgeheugen past. Nu Azure VM's biedt die maximaal 4 TB geheugen hebben, moet het haalbaar zijn om de werkset in het geheugen te houden. Daarom is het gebruik van buffergroepextensie beperkt tot enkele zeldzame gevallen en mag dit geen gangbare case zijn.

Overwegingen voor back-up/herstel voor SQL Server

Bij het implementeren SQL Server in Azure, moet uw back-upmethodologie worden gecontroleerd. Zelfs als het systeem geen productiesysteem is, moet er periodiek een back-up worden gemaakt van de SAP-database die door SQL Server wordt gehost. Omdat Azure Storage drie afbeeldingen bewaart, is een back-up nu minder belangrijk voor het compenseren van een opslagcrash. De prioriteitsreden voor het onderhouden van een juist back-up- en herstelplan is dat u logische/handmatige fouten kunt compenseren door herstelmogelijkheden voor een bepaald tijdstip te bieden. Het doel is dus om back-ups te gebruiken om de database terug te herstellen naar een bepaald tijdstip of om de back-ups in Azure te gebruiken om een ander systeem te seeden door de bestaande database te kopiëren.

Lees het SQL Server artikel Backup and Restore for SQL Server in Azure SQL Server in Azure Virtual Machines om verschillende back-upmogelijkheden in Azure te Virtual Machines. In dit artikel worden verschillende mogelijkheden beschreven.

Handmatige back-ups

U hebt verschillende mogelijkheden om 'handmatige' back-ups uit te voeren door:

1. Conventionele back-SQL Server uitvoeren op direct gekoppelde Azure-schijven. Deze methode heeft als voordeel dat u de back-ups snel beschikbaar hebt voor systeemvernieuwingen en het bouwen van nieuwe systemen als kopieën van bestaande SAP-systemen
2. SQL Server 2012 CU4 en hoger kunt u een back-up maken van databases naar een Azure Storage-URL.
3. File-Snapshot back-ups voor databasebestanden in Azure Blob Storage. Deze methode werkt alleen wanneer uw SQL Server en logboekbestanden zich in Azure Blob Storage bevinden

De eerste methode is bekend en wordt in veel gevallen ook in de on-premises wereld toegepast. U hebt echter de taak om de back-uplocatie voor de langere termijn op te lossen. Omdat u uw back-ups niet langer dan 30 dagen in de lokaal gekoppelde Azure Storage wilt bewaren, moet u Azure Backup Services of een ander hulpprogramma voor back-up/herstel van derden gebruiken dat toegangs- en bewaarbeheer voor uw back-ups bevat. U kunt ook een grote bestandsserver in Azure bouwen met behulp Windows opslagruimten.

De tweede methode wordt nader beschreven in het artikel SQL Server Back-up naar URL. Verschillende versies van SQL Server hebben enkele variaties in deze functionaliteit. Bekijk daarom de documentatie voor uw specifieke SQL Server releasecontrole. Houd er rekening mee dat in dit artikel talloze beperkingen worden vermeld. U hebt de mogelijkheid om de back-up uit te voeren op:

• Eén Azure-pagina-blob, die vervolgens de back-upgrootte beperkt tot 1000 GB. Deze beperking beperkt ook de doorvoer die u kunt bereiken.
• Meerdere (maximaal 64) Azure-blok-blobs, die een theoretische back-upgrootte van 12 TB mogelijk maken. Uit tests met klantdatabases blijkt echter dat de maximale back-upgrootte kleiner kan zijn dan de theoretische limiet. In dit geval bent u verantwoordelijk voor het beheren van de retentie van back-ups en toegang tot de back-ups.

Automatische back-up voor SQL Server

Automatische back-up biedt een automatische back-upservice voor SQL Server Standard- en Enterprise-edities die worden uitgevoerd in een Windows-VM in Azure. Deze service wordt geleverd door de IaaS SQL Server extensievoor IaaS-agent, die automatisch wordt geïnstalleerd op SQL Server Windows-installatie van virtuele machines in de Azure Portal. Als u uw eigen installatie van het besturingssysteem implementeert SQL Server geïnstalleerd, moet u de VM-extensies afzonderlijk installeren. De benodigde stappen worden beschreven in dit artikel.

Meer informatie over de mogelijkheden van deze methode vindt u in deze artikelen:

• SQL Server 2014: Automated Backup for SQL Server 2014 Virtual Machines (Resource Manager)
• SQL Server 2016/2017: Automated Backup v2 for Azure Virtual Machines (Resource Manager)

Als u de documentatie bekijkt, ziet u dat de functionaliteit met de recentere versies SQL Server verbeterd. Meer informatie over de SQL Server automatische back-ups wordt uitgebracht in het artikel SQL Server Managed Backup naar Microsoft Azure. De limiet voor de theoretische back-upgrootte is 12 TB. De automatische back-ups kunnen een goede methode zijn voor back-ups van maximaal 12 TB. Omdat meerdere blobs parallel naar worden geschreven, kunt u een doorvoer van meer dan 100 MB per seconde verwachten.

Azure Backup voor SQL Server-VM's

Deze nieuwe methode voor SQL Server back-ups wordt vanaf juni 2018 aangeboden als openbare preview door Azure Backup services. De methode voor het maken van back-SQL Server is hetzelfde als andere hulpprogramma's van derden, namelijk de VSS-/VDI-interface SQL Server om back-ups naar een doellocatie te streamen. In dit geval is de doellocatie Azure Recovery Service-kluis.

Een meer dan gedetailleerde beschrijving van deze back-upmethode, die talloze voordelen van centrale back-upconfiguraties, bewaking en beheer toevoegt, is beschikbaar op de pagina Back-up SQL Server databases naar Azure.

Back-upoplossingen van derden

Voor een groot aantal SAP-klanten was het niet mogelijk om opnieuw te beginnen en volledige nieuwe back-upoplossingen te introduceren voor het deel van hun SAP-landschap dat op Azure werd uitgevoerd. Als gevolg hiervan moesten de bestaande back-upoplossingen worden gebruikt en uitgebreid naar Azure. Het uitbreiden van bestaande back-upoplossingen naar Azure werkt meestal goed met de meeste van de belangrijkste leveranciers op dit werk.

Een SQL Server uit de marketplace Microsoft Azure maken

Microsoft biedt VM's in Azure Marketplace, die al versies van SQL Server. Voor SAP-klanten die licenties nodig hebben voor SQL Server en Windows, kan het gebruik van deze installatie afbeeldingen een kans zijn om te voldoen aan de noodzaak van licenties door VM's in te SQL Server die al zijn geïnstalleerd. Voor het gebruik van dergelijke afbeeldingen voor SAP moeten de volgende overwegingen worden gemaakt:

• De SQL Server niet-evaluatieversies krijgen hogere kosten dan een 'Windows'-VM die is geïmplementeerd vanuit Azure Marketplace. Zie deze artikelen om de prijzen te vergelijken: https://azure.microsoft.com/pricing/details/virtual-machines/windows/ en https://azure.microsoft.com/pricing/details/virtual-machines/sql-server-enterprise/ .
• U kunt alleen SQL Server releases, die worden ondersteund door SAP.
• De collatie van het SQL Server-exemplaar, dat is geïnstalleerd in de VM's die worden aangeboden in de Azure Marketplace, is niet de collatie die sap NetWeaver vereist dat het SQL Server-exemplaar wordt uitgevoerd. U kunt de collatie echter wijzigen met de aanwijzingen in de volgende sectie.

De SQL Server van een Microsoft-VM Windows/SQL Server wijzigen

Omdat de SQL Server in de Azure Marketplace niet zijn ingesteld voor het gebruik van de collatie, wat vereist is voor SAP NetWeaver-toepassingen, moet deze onmiddellijk na de implementatie worden gewijzigd. Voor SQL Server kan deze wijziging van de collatie worden uitgevoerd met de volgende stappen zodra de VM is geïmplementeerd en een beheerder zich kan aanmelden bij de geïmplementeerde VM:

• Open als Windows een opdrachtvenster.
• Wijzig de map in C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012.
• Voer de opdracht uit: Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS= <local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2
  • <local_admin_account_name> is het account, dat is gedefinieerd als het beheerdersaccount bij de eerste implementatie van de VM via de galerie.

Het proces duurt slechts enkele minuten. Voer de volgende stappen uit om te controleren of de stap het juiste resultaat heeft:

• Open SQL Server Management Studio.
• Open een queryvenster.
• Voer de opdracht sp_helpsort in de SQL Server-hoofddatabase.

Het gewenste resultaat moet er als volgende uitzien:

Latin1-General, binary code point comparison sort for Unicode Data, SQL Server Sort Order 40 on Code Page 850 for non-Unicode Data

Als het resultaat anders is, stopt u de implementatie van SAP en onderzoekt u waarom de installatieopdracht niet werkt zoals verwacht. Implementatie van SAP NetWeaver-toepassingen op SQL Server exemplaar met verschillende SQL Server codepagina's dan de hierboven genoemde, wordt NIET ondersteund.

SQL Server High-Availability voor SAP in Azure

Als SQL Server in Azure IaaS-implementaties voor SAP gebruikt, hebt u verschillende mogelijkheden om toe te voegen om de DBMS-laag zeer beschikbaar te implementeren. Zoals al besproken in Overwegingen voor Azure Virtual Machines DBMS-implementatie voor SAP-workload, biedt Azure verschillende up-time SLA's voor één VM en een paar VM's die zijn geïmplementeerd in een Azure-beschikbaarheidsset. Veronderstelling is dat u toe bent aan de up-time SLA voor uw productie-implementaties die de implementatie in Azure-beschikbaarheidssets vereist. In dat geval moet u minimaal twee VM's in een dergelijke beschikbaarheidsset implementeren. Op één VM wordt de actieve SQL Server uitgevoerd. Op de andere VM wordt het passieve exemplaar uitgevoerd

SQL Server Clusteren met Windows scale-out bestandsserver of gedeelde Azure-schijf

Met Windows Server 2016 heeft Microsoft direct Opslagruimten geïntroduceerd. Op basis Opslagruimten Direct Deployment wordt SQL Server FCI-clustering in het algemeen ondersteund. Azure biedt ook gedeelde Azure-schijven die kunnen worden gebruikt voor Windows clustering. Voor SAP-workloads ondersteunen we deze ha-opties niet.

SQL Server Logboekbestanden

Een van de methoden voor hoge beschikbaarheid (HA) is SQL Server logboekbestanden. Als de VM's die deel nemen aan de HA-configuratie een werkende naamom oplossing hebben, is er geen probleem. De installatie in Azure verschilt niet van elke configuratie die on-premises wordt uitgevoerd met betrekking tot het instellen van logboekverzending en de principes voor logboekverzending. Meer informatie over SQL Server vindt u in het artikel Over logboekbestanden (SQL Server).

De functionaliteit SQL Server verzending van logboekbestanden werd nauwelijks gebruikt in Azure om hoge beschikbaarheid binnen één Azure-regio te bereiken. In de volgende scenario's maakten SAP-klanten echter gebruik van een geslaagde verzending van logboeken met Azure:

• Noodherstelscenario's van de ene Azure-regio naar een andere Azure-regio
• Configuratie van herstel na noodherstel van on-premises naar een Azure-regio
• Cut-over scenario's van on-premises naar Azure. In dergelijke gevallen wordt de logboekverzending gebruikt om de nieuwe DBMS-implementatie in Azure te synchroniseren met het lopende on-premises productiesysteem. Op het moment van oversnijding wordt de productie afgesloten en wordt ervoor zorgt dat de laatste en meest recente transactielogboekback-ups zijn overgedragen naar de Azure DBMS-implementatie. Vervolgens wordt de Azure DBMS-implementatie geopend voor productie.

Databases spiegelen

Databasespiegeling zoals ondersteund door SAP (zie SAP Note 965908) is afhankelijk van het definiëren van een failoverpartner in de SAP-connection string. Voor de cross-premises gevallen gaan we ervan uit dat de twee VM's zich in hetzelfde domein en dat de gebruikerscontext de twee SQL Server-exemplaren worden uitgevoerd onder een domeingebruiker en voldoende bevoegdheden hebben in de twee betrokken SQL Server-exemplaren. Daarom verschilt de installatie van databasespiegeling in Azure niet tussen een typische on-premises installatie/configuratie.

Vanaf Cloud-Only implementaties is de eenvoudigste methode om een ander domein in Azure in te stellen om die DBMS-VM's (en idealiter toegewezen SAP-VM's) binnen één domein te hebben.

Als een domein niet mogelijk is, kunt u ook certificaten gebruiken voor de eindpunten voor databasespiegeling, zoals hier wordt beschreven: Certificaten gebruiken voor een Database Mirroring-eindpunt (Transact-SQL)

Een zelfstudie voor het instellen van databasespiegeling in Azure vindt u hier: Databasespiegeling (SQL Server)

SQL Server Always On

Omdat Always On wordt ondersteund voor SAP on-premises (zie SAP Note 1772688), wordt dit ondersteund in combinatie met SAP in Azure. Er zijn enkele speciale overwegingen voor het implementeren van de listener voor de SQL Server-beschikbaarheidsgroep (niet te verwarrend met de Azure-beschikbaarheidsset), omdat het op dit moment in Azure niet mogelijk is om een AD/DNS-object te maken, omdat dit on-premises mogelijk is. Daarom zijn er enkele verschillende installatiestappen nodig om het specifieke gedrag van Azure te ondervangen.

Enkele overwegingen bij het gebruik van een listener voor beschikbaarheidsgroep zijn:

• Het gebruik van een listener voor beschikbaarheidsgroep is alleen mogelijk Windows Server 2012 of hoger als gastbesturingssysteem van de VM. Voor Windows Server 2012 moet u ervoor zorgen dat deze patch wordt toegepast:https://support.microsoft.com/kb/2854082
• Voor Windows Server 2008 R2 bestaat deze patch niet en moet Always On op dezelfde manier worden gebruikt als Database Mirroring door een failoverpartner op te geven in de verbindingsreeks (gedaan via de SAP default.pfl parameter dbs/mss/server - zie SAP Note 965908).
• Wanneer u een listener voor een beschikbaarheidsgroep gebruikt, moeten de database-VM's zijn verbonden met een toegewezen Load Balancer. Om te voorkomen dat Azure nieuwe IP-adressen toewijst in gevallen waarin beide VM's worden afgesloten, moet u statische IP-adressen toewijzen aan de netwerkinterfaces van deze VM's in de Always On-configuratie (het definiëren van een statisch IP-adres wordt beschreven in dit artikel)
• Er zijn speciale stappen vereist bij het bouwen van de WSFC-clusterconfiguratie waarbij het cluster een speciaal IP-adres moet toewijzen, omdat Azure met de huidige functionaliteit hetzelfde IP-adres aan de clusternaam zou toewijzen als het knooppunt waarop het cluster is gemaakt. Dit gedrag betekent dat er een handmatige stap moet worden uitgevoerd om een ander IP-adres aan het cluster toe te wijzen.
• De listener voor beschikbaarheidsgroep wordt in Azure gemaakt met TCP/IP-eindpunten, die worden toegewezen aan de VM's waarop de primaire en secundaire replica's van de beschikbaarheidsgroep worden uitgevoerd.
• Het is mogelijk nodig om deze eindpunten te beveiligen met ACL's.

Gedetailleerde documentatie over het implementeren van Always On met SQL Server in azure-VM's, zoals:

• Maak kennis SQL Server Always On-beschikbaarheidsgroepen op virtuele Azure-machines.
• Configureer een Always On-beschikbaarheidsgroep op virtuele Azure-machines in verschillende regio's.
• Configureer een load balancer voor een Always On-beschikbaarheidsgroep in Azure.

SQL Server Always On is de meest gebruikte functionaliteit voor hoge beschikbaarheid en herstel na noodherstel die in Azure wordt gebruikt voor SAP-workloadimplementaties. De meeste klanten gebruiken Always On voor hoge beschikbaarheid binnen één Azure-regio. Als de implementatie is beperkt tot slechts twee knooppunten, hebt u twee opties voor connectiviteit:

• Met behulp van de listener voor beschikbaarheidsgroep. Met de listener voor beschikbaarheidsgroep moet u een Azure-load balancer.
• Gebruik SQL Server 2019 CU8 of recentere releases waarin u in plaats daarvan de DNN-listener (Direct Network Name) kunt gebruiken. Dit elimineert de vereiste voor een Azure-load balancer.
• Gebruik de connectiviteitsparameters SQL Server databasespiegeling. In dit geval moet u de connectiviteit van de SAP-toepassingen zodanig configureren dat beide knooppuntnamen een naam krijgen. Exacte details van een dergelijke SAP-configuratie worden beschreven in SAP Note #965908. Als u deze optie gebruikt, hoeft u geen listener voor beschikbaarheidsgroep te configureren. En daarmee is er geen Azure load balancer voor de SQL Server hoge beschikbaarheid. Deze optie werkt echter alleen als u uw beschikbaarheidsgroep beperkt tot meerdere exemplaren.

Een groot aantal klanten maakt gebruik van de SQL Server Always On-functionaliteit voor herstel na noodherstel tussen Azure-regio's. Verschillende klanten maken ook gebruik van de mogelijkheid om back-ups uit te voeren vanaf een secundaire replica.

SQL Server Transparent Data Encryption

Er zijn veel klanten die gebruikmaken van SQL Server Transparent Data Encryption (TDE) bij het implementeren van hun SAP SQL Server databases in Azure. De SQL Server TDE-functionaliteit wordt volledig ondersteund door SAP (zie SAP Note #1380493).

Een SQL Server toepassen

In gevallen waarin u een heterogene migratie van een andere DBMS, die on-premises wordt uitgevoerd, naar Windows/SQL Server die wordt uitgevoerd in Azure, moet u uw lege doeldatabase van tevoren in SQL Server maken. Als volgende stap moet u de TDE SQL Server functionaliteit toepassen. Terwijl u uw productiesysteem nog steeds on-premises gebruikt. De reden dat u in deze volgorde wilt uitvoeren, is dat het versleutelen van de lege database enige tijd kan duren. De SAP-importprocessen importeren de gegevens vervolgens in de versleutelde database tijdens de downtimefase. De overhead van het importeren in een versleutelde database heeft een veel lagere tijdsimpact dan het versleutelen van de database na de exportfase in de fase met een lagere tijd. Er zijn negatieve ervaringen opgedaan bij het toepassen van TDE met SAP-workload die boven op de database wordt uitgevoerd. Daarom wordt aanbevolen de implementatie van TDE te behandelen als een activiteit die moet worden uitgevoerd zonder SAP-workload op de specifieke database.

In gevallen waarin u SAP-SQL Server databases verplaatst van on-premises naar Azure, raden we u aan te testen op welke infrastructuur u de versleuteling het snelst kunt toepassen. Houd hiervoor rekening met de volgende feiten:

• U kunt niet definiëren hoeveel threads er worden gebruikt om gegevensversleuteling toe te passen op de database. Het aantal threads is sterk afhankelijk van het aantal schijfvolumes SQL Server gegevens en logboekbestanden worden gedistribueerd. Betekent dat hoe meer afzonderlijke volumes (station letters), hoe meer threads parallel worden betrokken om de versleuteling uit te voeren. Een dergelijke configuratie is in strijd met de eerdere suggestie voor schijfconfiguratie bij het bouwen van een of een kleiner aantal opslagruimten voor de SQL Server-databasebestanden in Azure-VM's. Een configuratie met een klein aantal volumes zou leiden tot een klein aantal threads die de versleuteling uitvoeren. Een versleuteling met één thread leest 64 kB-delen, versleutelt deze en schrijft vervolgens een record naar het transactielogboekbestand om aan te geven dat de mate is versleuteld. Als gevolg hiervan is de belasting van het transactielogboek gemiddeld.
• In oudere SQL Server versies werd back-upcompressie niet meer efficiënt toen u uw SQL Server versleuteld. Dit gedrag kan zich ontwikkelen tot een probleem wanneer uw plan was om uw SQL Server-database on-premises te versleutelen en vervolgens een back-up te kopiëren naar Azure om de database in Azure te herstellen. SQL Server back-upcompressie bereikt meestal een compressieverhouding van factor 4.
• Met SQL Server 2016 hebben SQL Server nieuwe functionaliteit geïntroduceerd waarmee versleutelde databases en op een efficiënte manier kunnen worden gecomprimeerd. Zie dit blog voor meer informatie.

Als u de toepassing van TDE-versleuteling alleen behandelt zonder of weinig SAP-workload, moet u in uw specifieke configuratie testen of het beter is om TDE toe te passen op uw SAP-database on-premises of om dit te doen in Azure. In Azure hebt u zeker meer flexibiliteit wat betreft over-inrichtingsinfrastructuur en verkleint u de infrastructuur nadat TDE is toegepast.

Met behulp van Azure Key Vault

Azure biedt de service van een Key Vault voor het opslaan van versleutelingssleutels. SQL Server aan de andere kant een connector voor het gebruik van Azure Key Vault als opslag voor de TDE-certificaten.

Meer informatie over het gebruik van Azure Key Vault voor SQL Server TDE-lijsten, zoals:

• Extensible Key Management met Azure Key Vault (SQL Server).
• SQL Server TDE extensible key management using Azure Key Vault - Setup Steps.
• SQL Server-connector voor & oplossen van problemen.
• Meer vragen van klanten over SQL Server Transparent Data Encryption – TDE + Azure Key Vault.

Algemene SQL Server voor SAP on Azure samenvatting

Er zijn veel aanbevelingen in deze handleiding en we raden u aan deze meer dan één keer te lezen voordat u uw Azure-implementatie plant. Over het algemeen moet u echter de belangrijkste algemene DBMS op Azure-specifieke aanbevelingen volgen:

1. Gebruik de nieuwste DBMS-release, zoals SQL Server 2017, die de meeste voordelen heeft in Azure.
2. Plan zorgvuldig uw SAP-systeemlandschap in Azure om de indeling van het gegevensbestand en de Azure-beperkingen in balans te brengen:
   • Niet te veel schijven hebben, maar voldoende om ervoor te zorgen dat u uw vereiste IOPS kunt bereiken.
   • Als u geen Managed Disks gebruikt, moet u er rekening mee houden dat IOPS ook per Azure Storage-account wordt beperkt en dat Storage-accounts zijn beperkt binnen elk Azure-abonnement (meerinformatie).
   • Stripe alleen over schijven als u een hogere doorvoer wilt bereiken.
3. Installeer nooit software of plaats bestanden waarvoor persistentie op de D:\ is vereist station omdat het niet-permanent is en alles op dit station verloren gaat wanneer Windows opnieuw opstart.
4. Gebruik geen schijf caching voor Azure Standard Storage.
5. Gebruik Azure Standard-accounts met geo-replicatie niet Storage Azure. Lokaal redundant gebruiken voor DBMS-workloads.
6. Gebruik de HA/DR-oplossing van uw DBMS-leverancier om databasegegevens te repliceren.
7. Gebruik altijd Naamresolutie, vertrouw niet op IP-adressen.
8. Gebruik SQL Server TDE om de meest recente patches SQL Server toepassen.
9. Gebruik de hoogst mogelijke databasecompressie. Dit is paginacompressie voor SQL Server.
10. Wees voorzichtig met het SQL Server van de Azure Marketplace. Als u de SQL Server gebruikt, moet u de instantieseratie wijzigen voordat u er SAP NetWeaver-systeem op installeert.
11. Installeer en configureer de SAP-hostbewaking voor Azure, zoals beschreven in Implementatiehandleiding.

Volgende stappen

Lees het artikel

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