Distribuzione DBMS per SQL Server di macchine virtuali di Azure per SAP NetWeaver

Articolo
06/01/2023

Il presente documento illustra le numerose aree da valutare quando si distribuisce SQL Server per un carico di lavoro SAP in IaaS di Azure. Prima di questo documento è consigliabile avere letto il documento Considerations for Azure Virtual Machines DBMS deployment for SAP workload (Considerazioni sulla distribuzione DBMS di macchine virtuali di Azure per un carico di lavoro SAP) e le altre guide disponibili nella documentazione relativa a un carico di lavoro SAP in Azure.

Importante

L'ambito di questo documento è la versione Windows di SQL Server. SAP non supporta la versione Linux di SQL Server con qualsiasi software SAP. Questo documento non illustra il database SQL di Microsoft Azure, una piattaforma distribuita come servizio offerta nell'ambito della piattaforma Microsoft Azure. La discussione in questo documento riguarda l'esecuzione del prodotto SQL Server, noto per le distribuzioni locali in Azure Macchine virtuali, sfruttando la funzionalità Infrastruttura distribuita come servizio di Azure. Le funzionalità e le funzionalità del database tra queste due offerte sono diverse e non devono essere combinate tra loro. Per altre informazioni, vedere database SQL di Azure.

Per eseguire i carichi di lavoro SAP in IaaS di Azure, è consigliabile in linea generale usare le versioni più recenti di SQL Server. Le versioni più recenti di SQL Server offrono una migliore integrazione con alcuni dei servizi e delle funzionalità di Azure o contengono modifiche che ottimizzano le operazioni in un'infrastruttura IaaS di Azure.

La documentazione generale su SQL Server in esecuzione nelle macchine virtuali di Azure è disponibile negli articoli seguenti:

Non tutte le istruzioni e il contenuto creati nella documentazione generale di SQL Server nella macchina virtuale di Azure si applicano al carico di lavoro SAP. Tuttavia, la documentazione dà una buona impressione sui principi. Un esempio per le funzionalità non supportate per il carico di lavoro SAP è l'uso del clustering fci.

Esistono alcune informazioni specifiche di SQL Server in IaaS che è necessario conoscere prima di continuare:

Supporto della versione di SQL: anche con la nota SAP #1928533 che indica che la versione minima supportata di SQL Server è SQL Server 2008 R2, la finestra delle versioni di SQL Server supportate in Azure è dettata anche dal ciclo di vita di SQL Server. La manutenzione estesa di SQL Server 2012 è terminata a metà del 2022. Di conseguenza, la versione minima corrente per i sistemi appena distribuiti deve essere SQL Server 2014. Più recente, meglio. Le versioni più recenti di SQL Server offrono una migliore integrazione con alcuni dei servizi e delle funzionalità di Azure o contengono modifiche che ottimizzano le operazioni in un'infrastruttura IaaS di Azure.
Uso di immagini disponibili in Azure Marketplace: il modo più rapido per distribuire una nuova VM di Microsoft Azure consiste nell'usare un'immagine disponibile in Azure Marketplace. In Azure Marketplace sono presenti immagini contenenti le versioni più recenti di SQL Server. Non è però possibile usare subito per le applicazioni SAP NetWeaver le immagini in cui SQL Server è già installato. In tali immagini sono infatti installate le regole di confronto predefinite di SQL Server e non quelle richieste dai sistemi SAP NetWeaver. Per usare queste immagini, vedere la procedura documentata nel capitolo Uso di un'immagine di SQL Server da Microsoft Azure Marketplace.
Supporto per più istanze di SQL Server in una singola macchina virtuale di Azure: questo metodo di distribuzione è supportato. Tuttavia, tenere presente le limitazioni delle risorse, in particolare per quanto riguarda la larghezza di banda di rete e archiviazione del tipo di macchina virtuale in uso. Le informazioni dettagliate sono disponibili nell'articolo Dimensioni per le macchine virtuali in Azure. Queste limitazioni di quota potrebbero impedire l'implementazione della stessa architettura a istanze multipla che è possibile implementare in locale. A partire dalla configurazione e dall'interferenza della condivisione delle risorse disponibili all'interno di una singola macchina virtuale, è necessario tenere in considerazione le stesse considerazioni dell'ambiente locale.
Più database SAP in una singola istanza di SQL Server in una singola macchina virtuale: sono supportate configurazioni simili alle seguenti. Le considerazioni relative a più database SAP che condividono le risorse condivise di una singola istanza di SQL Server sono le stesse delle distribuzioni locali. Tenere presenti altri limiti, ad esempio il numero di dischi che possono essere collegati a un tipo di macchina virtuale specifico. In alternativa, limiti di quota di rete e archiviazione di tipi di vm specifici, come dimensioni dettagliate per le macchine virtuali in Azure.

In base alla descrizione generale, al sistema operativo, ai file eseguibili di SQL Server, i file eseguibili SAP devono trovarsi o installare dischi di Azure separati. In genere, la maggior parte dei database di sistema di SQL Server non viene usata a livello elevato dal carico di lavoro SAP NetWeaver. Tuttavia, i database di sistema di SQL Server devono essere, insieme alle altre directory di SQL Server in un disco di Azure separato. SQL Server tempdb deve trovarsi nell'unità D:\ non gestita o in un disco separato.

Con tutti i tipi di VM certificati SAP (vedere SAP Note #1928533), i dati tempdb e i file di log possono essere inseriti nell'unità D:\ non persistente.
Con le versioni di SQL Server, in cui SQL Server installa tempdb con un file di dati per impostazione predefinita, è consigliabile usare più file di dati tempdb. Tenere presente che i volumi di unità D:\ sono diversi in termini di dimensioni e funzionalità in base al tipo di macchina virtuale. Per le dimensioni esatte dell'unità D:\ delle diverse VM, vedere l'articolo Dimensioni per le macchine virtuali Windows in Azure.

Queste configurazioni consentono a tempdb di usare più spazio e più importanti operazioni di I/O al secondo (I/O al secondo) e larghezza di banda di archiviazione rispetto all'unità di sistema è in grado di fornire. L'unità D:\ non persistente offre anche una migliore latenza e la velocità effettiva di I/O. Per determinare le dimensioni corrette del database tempdb, è possibile controllare le dimensioni di tempdb nei sistemi esistenti.

Nota

Se si memorizzano i file di dati di tempdb e il file di log in una cartella nell'unità D:\ creata personalmente, è necessario assicurarsi che la cartella esista dopo un riavvio della VM. Poiché l'unità D:\ può essere appena inizializzata dopo il riavvio di una macchina virtuale, è possibile cancellare tutte le strutture di file e directory. Una possibilità di ricreare le strutture di directory nell'unità D:\ prima dell'avvio del servizio SQL Server è documentata in questo articolo.

Una configurazione di macchina virtuale, che esegue SQL Server con un database SAP e in cui i dati tempdb e il file di log tempdb vengono inseriti nell'unità D:\ e nell'archiviazione Premium di Azure v1 o v2 sarà simile al seguente:

Diagram of simple VM disk configuration for SQL Server

Il diagramma mostra un caso semplice. Come illustrato nell'articolo Considerazioni per la distribuzione DBMS di Azure Macchine virtuali per il carico di lavoro SAP, il tipo di archiviazione di Azure, il numero e le dimensioni dei dischi dipendono da fattori diversi. È tuttavia consigliabile:

Per le distribuzioni più piccole e medie, usando un volume di grandi dimensioni, che contiene i file di dati di SQL Server. Il motivo di questa configurazione è che è più facile gestire carichi di lavoro di I/O diversi nel caso in cui i file di dati di SQL Server non abbiano lo stesso spazio disponibile. Mentre nelle distribuzioni di grandi dimensioni, in particolare nelle distribuzioni in cui il cliente si è trasferito con una migrazione di database eterogenea a SQL Server in Azure, sono stati usati dischi separati e quindi distribuiti i file di dati in tali dischi. Tale architettura ha esito positivo solo quando ogni disco ha lo stesso numero di file di dati, tutti i file di dati hanno le stesse dimensioni e hanno approssimativamente lo stesso spazio libero.
Usare l'unità D:\ per tempdb fintanto che le prestazioni sono sufficientemente buone. Se il carico di lavoro complessivo è limitato in prestazioni da tempdb che si trova nell'unità D:\, è necessario spostare tempdb nell'archiviazione Premium di Azure v1 o v2 oppure su disco Ultra come consigliato in questo articolo.

Il meccanismo di riempimento proporzionale di SQL Server distribuisce le letture e le scritture in tutti i file di dati purché tutti i file di dati di SQL Server abbiano le stesse dimensioni e abbiano lo stesso ritmo libero. SAP in SQL Server offre prestazioni ottimali quando le letture e le scritture vengono distribuite uniformemente in tutti i file di dati disponibili. Se un database contiene troppi file di dati o i file di dati esistenti sono altamente sbilanciati, il metodo migliore per correggere è un'esportazione e un'importazione R3load. Un'esportazione e un'importazione R3load comporta tempi di inattività e devono essere eseguiti solo se si verifica un problema di prestazioni ovvio che deve essere risolto. Se i file di dati sono solo dimensioni moderatamente diverse, aumentare tutti i file di dati alla stessa dimensione e SQL Server ribilancia i dati nel corso del tempo. SQL Server aumenta automaticamente i file di dati in modo uniforme se viene impostato il flag di traccia 1117 o se viene usato SQL Server 2016 o versione successiva.

Speciale per le macchine virtuali serie M

Per la macchina virtuale serie M di Azure, la latenza di scrittura nel log delle transazioni può essere ridotta rispetto alle prestazioni di Archiviazione Premium di Azure v1, quando si usa l'acceleratore di scrittura di Azure. Se la latenza fornita dall'archiviazione Premium v1 limita la scalabilità del carico di lavoro SAP, il disco in cui è archiviato il file di log delle transazioni di SQL Server può essere abilitato per l'acceleratore di scrittura. I dettagli sono disponibili nel documento relativo all'acceleratore di scrittura. L'acceleratore di scrittura di Azure non funziona con l'archiviazione Premium di Azure v2 e il disco Ultra. In entrambi i casi, la latenza è migliore rispetto a quella offerta da Archiviazione Premium di Azure v1.

Formattazione dei dischi

Per i dischi contenenti i file di dati e di log di SQL Server è necessario un blocco NTFS di dimensioni pari a 64 KB. Non è necessario formattare l'unità D:\ perché viene fornita preformattata.

Per evitare che il ripristino o la creazione di database inizializzi i file di dati zerondo il contenuto dei file, assicurarsi che il contesto utente in cui è in esecuzione il servizio SQL Server abbia le attività di manutenzione del volume a destra dell'utente. Per altre informazioni, vedere Inizializzazione immediata dei file di database.

SQL Server 2014 e versioni successive: archiviazione dei file di database direttamente in Archiviazione BLOB di Azure

In SQL Server 2014 e versioni successive è possibile archiviare file di database direttamente in Archiviazione BLOB di Azure senza il "wrapper" di un disco rigido virtuale. Questa funzionalità è stata concepita per risolvere le carenze degli anni di archiviazione a blocchi di Azure. In questi giorni non è consigliabile usare questo metodo di distribuzione e scegliere invece Archiviazione Premium di Azure v1, Archiviazione Premium v2 o Disco Ultra. A seconda dei requisiti.

Estensione del pool di buffer di SQL Server 2014

In SQL Server 2014 è stata introdotta una nuova funzionalità denominata estensione del pool di buffer. Questa funzionalità, anche se testata nel carico di lavoro SAP in Azure, non ha fornito miglioramenti nel carico di lavoro di hosting. Pertanto, non deve essere considerato

Considerazioni sul backup/ripristino per SQL Server

Distribuire SQL Server in Azure, è necessario esaminare l'architettura di backup. Anche se il sistema non è un sistema di produzione, è necessario eseguire periodicamente il backup del database SAP ospitato da SQL Server. Dal momento che in Archiviazione di Azure vengono mantenute tre immagini, ora un backup è meno importante rispetto alla compensazione di un arresto anomalo della risorsa di archiviazione. È opportuno predisporre un piano di backup e ripristino appropriato principalmente perché consente di risolvere gli errori logici/manuali fornendo funzionalità di ripristino temporizzato. L'obiettivo è usare i backup per ripristinare il database a un determinato punto nel tempo. Oppure per usare i backup in Azure per eseguire il seeding di un altro sistema copiando il database esistente.

Esistono diversi modi per eseguire il backup e il ripristino di database di SQL Server in Azure. Per ottenere la panoramica e i dettagli migliori, leggere il documento Backup e ripristino per SQL Server in macchine virtuali di Azure. L'articolo descrive molti modi diversi.

Uso di un'immagine di SQL Server da Microsoft Azure Marketplace

In Microsoft Azure Marketplace sono disponibili VM che contengono già versioni di SQL Server. Per i clienti SAP che necessitano delle licenze per SQL Server e Windows l'uso di queste immagini può essere un'opportunità per ottenere le licenze necessarie scegliendo le VM con SQL Server già installato. Per usare tali immagini per SAP, è necessario considerare quanto segue:

Le versioni non di valutazione di SQL Server acquisiscono costi più elevati rispetto a una macchina virtuale "solo Windows" distribuita da Azure Marketplace. Per confrontare i prezzi, vedere Prezzi di Windows Macchine virtuali e Prezzi di SQL Server Enterprise Macchine virtuali.
È possibile usare solo versioni di SQL Server supportate da SAP.
Le regole di confronto dell'istanza di SQL Server, installate nelle macchine virtuali offerte in Azure Marketplace, non sono le regole di confronto che SAP NetWeaver richiede l'esecuzione dell'istanza di SQL Server. È comunque possibile modificare le regole di confronto attenendosi alle istruzioni della sezione seguente.

Modifica delle regole di confronto SQL Server di una VM Microsoft Windows/SQL Server

Poiché le immagini di SQL Server in Azure Marketplace non sono configurate per l'uso delle regole di confronto, richieste dalle applicazioni SAP NetWeaver, è necessario modificarle immediatamente dopo la distribuzione. In SQL Server queste modifiche delle regole di confronto possono essere eseguite attenendosi alla procedura seguente non appena la VM è stata distribuita e un amministratore è in grado di accedervi:

Aprire una finestra di comando di Windows come amministratore.
Passare alla directory C:\Programmi\SQL Server\110\Setup Bootstrap\SQLServer2012.
Eseguire il comando: Setup.exe /QUIET /ACTION=REBUILDDATABA edizione Standard /INSTANCENAME=MSSQL edizione Standard RVER /SQLSYSADMINACCOUNTS=<local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2
- <local_admin_account_name> è l'account, definito come account amministratore durante la distribuzione della macchina virtuale per la prima volta tramite la raccolta.

Il processo dovrebbe richiedere solo alcuni minuti. Per verificare la correttezza del risultato finale del passaggio, seguire questa procedura:

Aprire SQL Server Management Studio.
Aprire una finestra di query.
Eseguire il comando sp_helpsort nel database master di SQL Server.

Il risultato dovrebbe essere simile a quello della figura seguente:

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

Se il risultato è diverso, arrestare qualsiasi distribuzione ed esaminare il motivo per cui il comando di installazione non funziona come previsto. La distribuzione di applicazioni SAP NetWeaver nell'istanza di SQL Server con tabelle codici di SQL Server diverse da quelle indicate non è supportata per le distribuzioni NetWeaver.

Disponibilità elevata di SQL Server per SAP in Azure

Se si usa SQL Server nelle distribuzioni IaaS di Azure per SAP, sono disponibili molte possibilità per distribuire il livello DBMS a disponibilità elevata. Azure offre contratti di servizio diversi per una singola macchina virtuale usando archiviazioni a blocchi di Azure diverse, una coppia di macchine virtuali distribuite in un set di disponibilità di Azure o una coppia di macchine virtuali distribuite in Azure zone di disponibilità. Per i sistemi di produzione, si prevede di distribuire una coppia di macchine virtuali all'interno di un set di scalabilità di macchine virtuali con orchestrazione flessibile in due zone di disponibilità. Per altre informazioni, vedere confronto tra diversi tipi di distribuzione per il carico di lavoro SAP. Una macchina virtuale viene eseguita nell'istanza di SQL Server attiva. L'altra macchina virtuale eseguirà l'istanza passiva

Clustering di SQL Server con file server con scalabilità orizzontale Windows o disco condiviso di Azure

Con Windows Server 2016, Microsoft ha introdotto la funzionalità Spazi di archiviazione diretta. In base a spazi Archiviazione, distribuzione diretta, clustering dell'istanza del cluster di failover di SQL Server è supportato in generale. Azure offre anche dischi condivisi di Azure che possono essere usati per il clustering di Windows. Per il carico di lavoro SAP non sono supportate queste opzioni a disponibilità elevata.

Log shipping SQL Server

Una funzionalità a disponibilità elevata è il log shipping di SQL Server. Se le macchine virtuali che partecipano alla configurazione a disponibilità elevata hanno una risoluzione dei nomi funzionanti, non esiste alcun problema. La configurazione in Azure non differisce da qualsiasi configurazione eseguita in locale per configurare il log shipping e i principi relativi al log shipping. Per informazioni dettagliate sul log shipping di SQL Server, vedere l'articolo Informazioni sul log shipping (SQL Server).

La funzionalità di log shipping di SQL Server viene usata raramente in Azure per ottenere la disponibilità elevata in una singola area di Azure. Tuttavia, negli scenari seguenti i clienti SAP usano correttamente il log shipping con Azure:

Scenari di ripristino di emergenza da un'area di Azure in un'altra area di Azure
Configurazione di ripristino di emergenza da un'area locale in un'area di Azure
Scenari di cutover da un'area locale ad Azure. In questi casi, il log shipping viene usato per sincronizzare la nuova distribuzione DBMS in Azure con l'ambiente di produzione in uso nel sistema locale. Al momento del taglio, la produzione viene arrestata ed è stato verificato che gli ultimi backup del log delle transazioni siano stati trasferiti alla distribuzione DBMS di Azure. La distribuzione DBMS in Azure viene quindi aperta per la produzione.

SQL Server AlwaysOn

Poiché Always On è supportato per SAP locale (vedere la nota SAP #1772688), è supportato in combinazione con SAP in Azure. Esistono alcune considerazioni speciali per la distribuzione del listener del gruppo di disponibilità di SQL Server (da non confondere con il set di disponibilità di Azure). Di conseguenza, sono necessari alcuni passaggi di installazione diversi.

Di seguito sono elencate alcune considerazioni relative all'uso di un listener del gruppo di disponibilità.

L'uso di un listener del gruppo di disponibilità è possibile solo se il sistema operativo guest della VM è Windows Server 2012 o versioni successive. Per Windows Server 2012, assicurarsi che sia stato applicato l'aggiornamento per abilitare listener del gruppo di disponibilità di SQL Server in Windows Server 2008 R2 e windows Server 2012.
Per Windows Server 2008 R2, questa patch non esiste. In questo caso, è necessario usare Always On nello stesso modo del mirroring del database. Specificando un partner di failover nella stringa di connessioni (eseguita tramite il parametro SAP default.pfl dbs/mss/server. Vedere la nota SAP #965908).
Usando un listener del gruppo di disponibilità, è necessario connettere le macchine virtuali di database a un servizio di bilanciamento del carico dedicato. È consigliabile assegnare indirizzi IP statici alle interfacce di rete di tali macchine virtuali nella configurazione AlwaysOn (la definizione di un indirizzo IP statico è descritta in questo articolo). Gli indirizzi IP statici rispetto a DHCP impediscono l'assegnazione di nuovi indirizzi IP nei casi in cui entrambe le macchine virtuali potrebbero essere arrestate.
La procedura di creazione della configurazione cluster WSFC prevede speciali passaggi quando è necessario assegnare al cluster un indirizzo IP particolare, dal momento che Azure con la funzionalità corrente assegna al nome del cluster lo stesso indirizzo IP del nodo in cui viene creato il cluster. Questo comportamento significa che è necessario eseguire un passaggio manuale per assegnare un indirizzo IP diverso al cluster.
Il listener del gruppo di disponibilità verrà creato in Azure con gli endpoint TCP/IP assegnati alle VM che eseguono le repliche primaria e secondaria del gruppo di disponibilità.
Potrebbe essere necessario proteggere questi endpoint con ACL.

Di seguito è elencata la documentazione dettagliata sulla distribuzione di Always On con SQL Server in macchine virtuali di Azure:

Nota

Leggere Introduzione ai gruppi di disponibilità Always On di SQL Server nelle macchine virtuali di Azure. Si leggerà il listener DNN (Direct Network Name) di SQL Server. Questa nuova funzionalità è stata introdotta con SQL Server 2019 CU8. Questa nuova funzionalità rende obsoleto l'utilizzo di un servizio di bilanciamento del carico di Azure che gestisce l'indirizzo IP virtuale del listener del gruppo di disponibilità.

SQL Server AlwaysOn è la funzionalità di disponibilità elevata e ripristino di emergenza più comunemente usata in Azure per le distribuzioni del carico di lavoro SAP. La maggior parte dei clienti usa Always On per la disponibilità elevata all'interno di una singola area di Azure. Se la distribuzione è limitata a due soli nodi, sono disponibili due opzioni per la connettività:

Utilizzo del listener del gruppo di disponibilità. Con il listener del gruppo di disponibilità è necessario distribuire un servizio di bilanciamento del carico di Azure.
Con SQL Server 2016 SP3, SQL Server 2017 CU 25 o SQL Server 2019 CU8 o versioni più recenti di SQL Server in Windows Server 2016 o versioni successive è possibile usare il listener DNN (Direct Network Name) anziché un servizio di bilanciamento del carico di Azure. DNN elimina il requisito di un servizio di bilanciamento del carico di Azure.

L'uso dei parametri di connettività del mirroring del database di SQL Server deve essere considerato solo per l'analisi dei problemi con gli altri due metodi. In questo caso, è necessario configurare la connettività delle applicazioni SAP in modo che entrambi i nomi dei nodi siano nominati. I dettagli precisi di tale configurazione lato SAP sono illustrati nella nota SAP #965908. Se si usa questa opzione, è necessario configurare un listener del gruppo di disponibilità. E senza il servizio di bilanciamento del carico di Azure e con questo potrebbe analizzare i problemi di tali componenti. Si deve tuttavia tenere presente che questa opzione funziona solo se si limita il gruppo di disponibilità a due istanze.

La maggior parte dei clienti usa la funzionalità Always On di SQL Server per la funzionalità di ripristino di emergenza tra aree di Azure. Molti clienti usano anche la possibilità di eseguire il backup da una replica secondaria.

Transparent Data Encryption di SQL Server

Molti clienti usano TDE (Transparent Data Encryption) di SQL Server durante la distribuzione dei database SAP SQL Server in Azure. La funzionalità TDE di SQL Server è completamente supportata da SAP (vedere la nota SAP #1380493).

Applicazione della funzionalità TDE di SQL Server

Nei casi in cui si esegue una migrazione eterogenea da un altro DBMS in esecuzione in locale verso Windows/SQL Server in esecuzione in Azure, è consigliabile creare in anticipo il database di destinazione vuoto in SQL Server. Come passaggio successivo si applicherà la funzionalità TDE di SQL Server a questo database vuoto. Il motivo per cui conviene attenersi a questa sequenza è che il processo di crittografia del database vuoto può richiedere molto tempo. I processi di importazione SAP importano quindi i dati nel database crittografato durante la fase di inattività. Nel complesso l'importazione in un database crittografato ha un impatto temporale inferiore rispetto alla crittografia del database dopo la fase di esportazione nella fase di inattività. Esperienze negative si sono verificate nel tentativo di applicare la funzionalità TDE con il carico di lavoro SAP in esecuzione sopra al database. Pertanto, è consigliabile considerare la distribuzione di TDE come un'attività che deve essere eseguita senza carico di lavoro SAP o basso nel database specifico. Da SQL Server 2016 in è possibile arrestare e riprendere l'analisi TDE che esegue la crittografia iniziale. Il documento Transparent Data Encryption (TDE) descrive il comando e i dettagli.

Nei casi in cui si spostano i database di SQL Server per SAP dal livello locale in Azure, è consigliabile testare in quale infrastruttura è possibile applicare la crittografia più velocemente. Per questo caso, tenere presenti questi fatti:

Non è possibile definire il numero di thread che viene usato per applicare la crittografia dei dati al database. Il numero di thread dipende principalmente dal numero di volumi di disco in cui sono distribuiti i file di dati e di log SQL Server. Questo significa che maggiore è il numero di volumi distinti (lettere delle unità), maggiore sarà il numero di thread impegnati in parallelo per eseguire la crittografia. Tale configurazione è un po' in contrasto con il suggerimento precedente sulla configurazione del disco che prevede la creazione di un numero inferiore di spazi di archiviazione, o di uno solo, per i file di database di SQL Server in macchine virtuali di Azure. Una configurazione con alcuni volumi comporta l'esecuzione della crittografia da parte di alcuni thread. La crittografia a thread singolo sta leggendo extent di 64 KB, la crittografa e quindi scrive un record nel file di log delle transazioni, in modo da indicare che l'extent è stato crittografato. Il carico sul log delle transazioni risulta così moderato.
Nelle versioni precedenti di SQL Server, la compressione dei backup non ha più avuto efficienza quando è stato crittografato il database di SQL Server. Questo comportamento potrebbe trasformarsi in un problema quando si pianifica di crittografare il database SQL locale e quindi copiare un backup in Azure per ripristinare il database in Azure. La compressione dei backup di SQL Server può ottenere un rapporto di compressione di fattore 4.
Con SQL Server 2016, SQL Server ha introdotto nuove funzionalità che consentono di comprimere il backup dei database crittografati in modo efficiente. Per altri dettagli, vedere questo blog .

Uso di Azure Key Vault

Azure offre il servizio Key Vault per archiviare le chiavi di crittografia. SQL Server dall'altro lato offre un connettore per l'uso di Azure Key Vault come archivio per i certificati TDE.

Altre informazioni sull'utilizzo di Azure Key Vault per TDE di SQL Server sono disponibili in:

Configurare l'integrazione di Azure Key Vault per SQL Server in macchine virtuali di Azure (Resource Manager).
More Questions From Customers About SQL Server Transparent Data Encryption – TDE + Azure Key Vault (Altre domande dei clienti sulla funzionalità Transparent Data Encryption di SQL Server - TDE + Azure Key Vault).

Importante

Con SQL Server TDE, in particolare con Azure Key Vault, è consigliabile usare le patch più recenti di SQL Server 2014, SQL Server 2016 e SQL Server 2017. Il motivo è che in base ai commenti e suggerimenti ricevuti dai clienti, al codice sono state applicate ottimizzazioni e correzioni. Controllare ad esempio KBA #4058175.

Configurazioni minime di distribuzione

In questa sezione viene suggerito un set di configurazioni minime per dimensioni diverse dei database nel carico di lavoro SAP. È troppo difficile valutare se queste dimensioni rientrano nel carico di lavoro specifico. In alcuni casi, è possibile che la memoria sia generosa rispetto alle dimensioni del database. D'altra parte, il ridimensionamento del disco potrebbe essere troppo basso per alcuni dei carichi di lavoro. Pertanto, queste configurazioni devono essere considerate come quelle che sono. Si tratta di configurazioni che dovrebbero dare un punto di partenza. Configurazioni per ottimizzare i requisiti specifici di carico di lavoro e efficienza dei costi.

Un esempio di configurazione per un'istanza di SQL Server con dimensioni del database comprese tra 50 GB e 250 GB potrebbe essere simile al seguente

Configurazione	DBMS VM	Commenti
Tipo di VM	E4s_v3/v4/v5 (4 vCPU/32 GiB RAM)
Rete accelerata	Abilitazione
Versione di SQL Server	SQL Server 2019 o più recenti
Numero di file di dati di	4
# dei file di log	1
Numero di file di dati temporanei	4 o impostazione predefinita a partire da SQL Server 2016
Sistema operativo	Windows Server 2019 o più recenti
Aggregazione del disco	Archiviazione Spazi, se necessario
File system	NTFS
Formato delle dimensioni del blocco	64 kB
# e tipo di dischi dati	Archiviazione Premium v1: 2 x P10 (RAID0) Archiviazione Premium v2: 2 x 150 GiB (RAID0) - Operazioni di I/O al secondo e velocità effettiva predefinite	Cache = Sola lettura per l'archiviazione Premium v1
# e tipo di dischi di log	Archiviazione Premium v1: 1 x P20 Archiviazione Premium v2: 1 x 128 GiB - Operazioni di I/O al secondo e velocità effettiva predefinite	Cache = NONE
Parametro max memory di SQL Server	90% di RAM fisica	Presupponendo una singola istanza

Un esempio di configurazione o di un'istanza di SQL Server di piccole dimensioni con dimensioni del database comprese tra 250 GB e 750 GB, ad esempio un sistema SAP Business Suite più piccolo, potrebbe essere simile al seguente:

Configurazione	DBMS VM	Commenti
Tipo di VM	E16s_v3/v4/v5 (16 vCPU/128 GiB RAM)
Rete accelerata	Abilitazione
Versione di SQL Server	SQL Server 2019 o più recenti
Numero di file di dati di	8
# dei file di log	1
Numero di file di dati temporanei	8 o impostazione predefinita a partire da SQL Server 2016
Sistema operativo	Windows Server 2019 o più recenti
Aggregazione del disco	Archiviazione Spazi, se necessario
File system	NTFS
Formato delle dimensioni del blocco	64 kB
# e tipo di dischi dati	Archiviazione Premium v1: 4 x P20 (RAID0) Archiviazione Premium v2: 4 x 100 GiB - 200 GiB (RAID0) - Operazioni di I/O al secondo predefinite e velocità effettiva aggiuntiva di 25 MB/sec per disco	Cache = Sola lettura per l'archiviazione Premium v1
# e tipo di dischi di log	Archiviazione Premium v1: 1 x P20 Archiviazione Premium v2: 1 x 200 GiB - Operazioni di I/O al secondo e velocità effettiva predefinite	Cache = NONE
Parametro max memory di SQL Server	90% di RAM fisica	Presupponendo una singola istanza

Un esempio di configurazione per un'istanza di SQL Server di medie dimensioni con dimensioni del database comprese tra 750 GB e 2.000 GB, ad esempio un sistema SAP Business Suite di medie dimensioni, potrebbe essere simile al seguente:

Configurazione	DBMS VM	Commenti
Tipo di VM	E64s_v3/v4/v5 (64 vCPU/432 GiB RAM)
Rete accelerata	Abilitazione
Versione di SQL Server	SQL Server 2019 o più recenti
Numero di dispositivi dati	16
Numero di dispositivi di log	1
Numero di file di dati temporanei	8 o impostazione predefinita a partire da SQL Server 2016
Sistema operativo	Windows Server 2019 o più recenti
Aggregazione del disco	Archiviazione Spazi, se necessario
File system	NTFS
Formato delle dimensioni del blocco	64 kB
# e tipo di dischi dati	Archiviazione Premium v1: 4 x P30 (RAID0) Archiviazione Premium v2: 4 x 250 GiB - 500 GiB - più 2.000 operazioni di I/O al secondo e velocità effettiva di 75 MB/sec per disco	Cache = Sola lettura per l'archiviazione Premium v1
# e tipo di dischi di log	Archiviazione Premium v1: 1 x P20 Archiviazione Premium v2: 1 x 400 GiB - Operazioni di I/O al secondo predefinite e velocità effettiva aggiuntiva di 75 MB/sec	Cache = NONE
Parametro max memory di SQL Server	90% di RAM fisica	Presupponendo una singola istanza

Un esempio di configurazione per un'istanza di SQL Server di dimensioni maggiori con dimensioni del database comprese tra 2.000 GB e 4.000 GB, ad esempio un sistema SAP Business Suite più grande, potrebbe essere simile al seguente:

Configurazione	DBMS VM	Commenti
Tipo di VM	E96(d)s_v5 (96 vCPU/672 GiB RAM)
Rete accelerata	Abilitazione
Versione di SQL Server	SQL Server 2019 o più recenti
Numero di dispositivi dati	24
Numero di dispositivi di log	1
Numero di file di dati temporanei	8 o impostazione predefinita a partire da SQL Server 2016
Sistema operativo	Windows Server 2019 o più recenti
Aggregazione del disco	Archiviazione Spazi, se necessario
File system	NTFS
Formato delle dimensioni del blocco	64 kB
# e tipo di dischi dati	Archiviazione Premium v1: 4 x P30 (RAID0) Archiviazione Premium v2: 4 x 500 GiB - 800 GiB - più 2500 operazioni di I/O al secondo e velocità effettiva di 100 MB/sec per disco	Cache = Sola lettura per l'archiviazione Premium v1
# e tipo di dischi di log	Archiviazione Premium v1: 1 x P20 Archiviazione Premium v2: 1 x 400 GiB - più 1.000 operazioni di I/O al secondo e velocità effettiva aggiuntiva di 75 MB/sec	Cache = NONE
Parametro max memory di SQL Server	90% di RAM fisica	Presupponendo una singola istanza

Un esempio di configurazione per un'istanza di SQL Server di grandi dimensioni con dimensioni del database pari a 4 TB+, ad esempio un sistema SAP Business Suite di grandi dimensioni usato a livello globale, potrebbe essere simile al seguente:

Configurazione	DBMS VM	Commenti
Tipo di VM	Serie M (da 1,0 a 4,0 TB di RAM)
Rete accelerata	Abilitazione
Versione di SQL Server	SQL Server 2019 o più recenti
Numero di dispositivi dati	32
Numero di dispositivi di log	1
Numero di file di dati temporanei	8 o impostazione predefinita a partire da SQL Server 2016
Sistema operativo	Windows Server 2019 o più recenti
Aggregazione del disco	Archiviazione Spazi, se necessario
File system	NTFS
Formato delle dimensioni del blocco	64 kB
# e tipo di dischi dati	Archiviazione Premium v1: 4+ x P40 (RAID0) Archiviazione Premium v2: 4+ x 1.000 GiB - 4.000 GiB - più 4.500 operazioni di I/O al secondo e velocità effettiva di 125 MB/sec per disco	Cache = Sola lettura per l'archiviazione Premium v1
# e tipo di dischi di log	Archiviazione Premium v1: 1 x P30 Archiviazione Premium v2: 1 x 500 GiB - più 2.000 operazioni di I/O al secondo e velocità effettiva di 125 MB/sec	Cache = NONE
Parametro max memory di SQL Server	95% di RAM fisica	Presupponendo una singola istanza

Ad esempio, questa configurazione è la configurazione della macchina virtuale DBMS di sap Business Suite in SQL Server. Questa macchina virtuale ospita il database di 30 TB della singola istanza globale di SAP Business Suite di una società globale con ricavi annuali superiori a 200 MILIARDI di dollari e oltre 200.000 dipendenti a tempo pieno. Il sistema esegue tutte le elaborazioni finanziarie, le vendite e la distribuzione e molti altri processi aziendali fuori da aree diverse, tra cui America del Nord n retribuzione. Il sistema è in esecuzione in Azure dall'inizio del 2018 usando macchine virtuali serie M di Azure come macchine virtuali DBMS. Poiché la disponibilità elevata del sistema usa Always On con una replica sincrona in un'altra zona di disponibilità della stessa area di Azure e un'altra replica asincrona in un'altra area di Azure. Il livello dell'applicazione NetWeaver viene distribuito nelle macchine virtuali Ev4.

Configurazione	DBMS VM	Commenti
Tipo di VM	M192dms_v2 (192 vCPU/4.196 GiB RAM)
Rete accelerata	Attivato
Versione di SQL Server	SQL Server 2019
Numero di file di dati di	32
# dei file di log	1
Numero di file di dati temporanei	8
Sistema operativo	Windows Server 2019
Aggregazione del disco	Spazi di archiviazione
File system	NTFS
Formato delle dimensioni del blocco	64 kB
# e tipo di dischi dati	Archiviazione Premium v1: 16 x P40	Cache = Sola lettura
# e tipo di dischi di log	Archiviazione Premium v1: 1 x P60	Uso dell'acceleratore di scrittura
# e tipo di dischi tempdb	Archiviazione Premium v1: 1 x P30	Nessuna memorizzazione nella cache
Parametro max memory di SQL Server	95% di RAM fisica

Riepilogo generale su SQL Server per SAP in Azure

Questa guida contiene numerosi consigli che è preferibile leggere più volte prima di pianificare la distribuzione di Azure. In linea generale, assicurarsi di seguire i principali consigli generali, specifici per la distribuzione di DBMS in Azure:

Usare la versione più recente di DBMS, ad esempio SQL Server 2019, con i vantaggi più significativi in Azure.
Pianificare attentamente il panorama del sistema SAP in Azure per bilanciare il layout dei file di dati e le restrizioni di Azure:
- Non usare troppi dischi, ma un numero sufficiente a garantire il numero necessario di operazioni di I/O al secondo.
  - Se è necessaria una velocità effettiva maggiore, eseguire lo striping solo tra dischi.
Non installare mai il software o inserire file che richiedono la persistenza nell'unità D:\ perché non è permanente e qualsiasi elemento in questa unità può essere perso in un riavvio di Windows o in un riavvio della macchina virtuale.
Usare la soluzione di disponibilità elevata/ripristino di emergenza del fornitore del sistema DBMS per replicare i dati del database.
Usare sempre la risoluzione dei nomi e non fare affidamento sugli indirizzi IP.
Quando si usa la funzionalità TDE di SQL Server, applicare le patch più recenti di SQL Server.
Prestare attenzione quando si usano immagini di SQL da Azure Marketplace. Se si usa quella di SQL Server, è necessario modificare le regole di confronto dell'istanza prima di installarvi un qualsiasi sistema SAP NetWeaver.
Installare e configurare la funzionalità di monitoraggio dell'host SAP per Azure come illustrato nella Guida alla distribuzione.

Passaggi successivi

Leggi l'articolo

Considerazioni sulla distribuzione DBMS di macchine virtuali di Azure per un carico di lavoro SAP