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

Il presente documento illustra le numerose aree da valutare quando si distribuisce SQL Server per un carico di lavoro SAP in IaaS di Azure. Come precondizione per questo documento, leggere il documento Considerazioni per la distribuzione DBMS di Azure Macchine virtuali per il carico di lavoro SAP e altre guide nella documentazione del carico di lavoro SAP in 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 in Azure Macchine virtuali (VM) è disponibile negli articoli seguenti:

• SQL Server in Macchine virtuali di Azure (Windows)
• Automatizzare la gestione con l'estensione dell'agente IaaS per SQL Server di Windows
• Configurare l'integrazione di Azure Key Vault per SQL Server nelle macchine virtuali di Azure (Resource Manager)
• Elenco di controllo: procedure consigliate per SQL Server nelle macchine virtuali di Azure
• Vedere Archiviazione: procedure consigliate per le prestazioni per SQL Server nelle macchine virtuali di Azure
• Procedure consigliate per la configurazione HADR (SQL Server nelle macchine virtuali di Azure)

Non tutte le istruzioni e il contenuto creati nella documentazione generale relativa a SQL Server nella macchina virtuale di Azure si applicano al carico di lavoro SAP. Tuttavia, la documentazione ne illustra bene principi. Un esempio per le funzionalità non supportate per il carico di lavoro SAP è l'uso del clustering fcI.

Di seguito sono indicate alcune informazioni specifiche su SQL Server in IaaS che è necessario conoscere per poter 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 distribuiti di recente deve essere SQL Server 2014. È consigliabile usare sempre la versione più recente. 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. Il motivo è che le regole di confronto predefinite di SQL Server vengono installate all'interno di tali immagini e non le regole di confronto necessarie per i 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 all'interno di 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 di archiviazione del tipo di macchina virtuale in uso. Le informazioni dettagliate sono disponibili nell'articolo Dimensioni delle macchine virtuali in Azure. Queste limitazioni di quota potrebbero impedire l'implementazione della stessa architettura a più istanze che è possibile implementare in locale. A partire dalla configurazione e dall'interferenza della condivisione delle risorse disponibili in una singola macchina virtuale, è necessario tenere presente 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 a queste. 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. Oppure i limiti di quota di rete e archiviazione di tipi di macchina virtuale specifici come illustrato in Dimensioni delle macchine virtuali in Azure.

Nuove macchine virtuali serie M e SQL Server

Azure ha rilasciato alcune nuove famiglie di SKU serie M nella famiglia di Mv3. Alcuni tipi di vm in questa famiglia non devono essere usati per SQL Server, incluso SQL Server 2022 senza disabilitare SMT (Hyperthreading) nel sistema operativo guest di Windows Server. Il motivo è il numero di nodi NUMA presentati nel sistema operativo guest windows Server che con più di 64 vCPU è troppo grande per SQL Server. Disabilitando SMT nel sistema operativo guest di Windows Server, il numero di vCPU viene ridotto. Di conseguenza, il numero di vCPU è minore di 64 in ogni nodo NUMA. Il modo in cui disabilitare SMT è descritto qui. I tipi di macchina virtuale specifici sono:

• M176(d)s_3_v3: disabilitare SMT o usare M176bds_4_v3 o M176bds_4_v3 come alternativa
• M176(d)s_4_v3: disabilitare SMT o usare M176bds_4_v3 come alternativa
• M624(d)s_12_v3: disabilitare SMT o usare M416ms_v2 come alternativa
• M832(d)s_12_v3: disabilitare SMT o usare M416ms_v2 come alternativa
• M832i(d)s_16_v3 : disabilitare SMT o usare M416ms_v2 come alternativa

Raccomandazioni sulla struttura di VM/dischi rigidi virtuali per distribuzioni di SQL Server correlate a SAP

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

• Con tutti i tipi di VM certificati SAP (vedere SAP Note #1928533), i dati di tempdb e i file di log possono essere inseriti nell'unità D:\ non gestita.
• Con le versioni di SQL Server, in cui SQL Server installa tempdb con un solo file di dati, è consigliabile usare più file di dati tempdb. Tenere presente che i volumi dell'unità D:\ hanno dimensioni e funzionalità diversi 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, cosa più importante, più operazioni di I/O al secondo e larghezza di banda di archiviazione rispetto a quanto l'unità di sistema sia in grado di fornire. L'unità D:\ non persistente offre anche una migliore latenza di I/O e velocità effettiva. Per determinare le dimensioni corrette del database tempdb, è possibile controllare le dimensioni di tempdb nei sistemi esistenti.

Una configurazione della macchina virtuale che esegue SQL Server con un database SAP e in cui i dati e il file di log di tempdb si trovano nell'unità D:\ e nell'archiviazione Premium di Azure v1 o v2 è simile a quella illustrata nella figura seguente:

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

• Per le distribuzioni più piccole e di dimensioni medie, che usano 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 è spostato in SQL Server di Azure con una migrazione di database eterogenea, sono stati usati dischi separati e quindi i file di dati sono stati distribuiti in tali dischi. Tale architettura viene usata con successo 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 di 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 operazioni di lettura e scrittura in tutti i file di dati purché tutti i file di dati di SQL Server abbiano le stesse dimensioni e lo stesso spazio 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 un numero troppo basso di file di dati o i file di dati esistenti sono altamente sbilanciati, il metodo migliore per correggere questa situazione è un'esportazione e un'importazione R3load. Un'operazione di esportazione e importazione R3load comporta tempi di inattività e deve essere eseguita solo se si verifica un evidente problema di prestazioni 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 il flag di traccia 1117 è impostato o se SQL Server 2016 o versione successiva viene usato senza flag di traccia.

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, in confronto 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 generata da archiviazione Premium di Azure v1. L'acceleratore di scrittura non supporta SSD Premium v2.

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 e che il loro contenuto venga azzerato, assicurarsi che per il contesto utente in cui viene eseguito il servizio SQL Server abbia il diritto utente Eseguire attività di manutenzione del volume. Per altre informazioni, vedere Inizializzazione immediata dei file di database.

SQL Server 2014 e versioni più recenti di SQL Server - Archiviazione di 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 precedenti dell'archiviazione a blocchi di Azure. In questi giorni non è consigliabile usare questo metodo di distribuzione, scegliere invece archiviazione Premium di Azure v1, archiviazione Premium v2 o archiviazione su disco Ultra a seconda delle necessità.

Considerazioni sul backup/ripristino per SQL Server

Durante la distribuzione di 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 di 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. La priorità per la gestione di un piano di backup e ripristino appropriato è importante per la funzionalità di ripristino temporizzato per compensare gli errori logici/manuali. L'obiettivo è usare i backup per ripristinare il database a un determinato punto nel tempo. In alternativa, usare i backup in Azure per eseguire il seeding di un altro sistema con la copia del backup del database esistente.

Esistono diversi modi per eseguire il backup e il ripristino dei 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

Microsoft offre macchine virtuali in Azure Marketplace, che contiene 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:

• I costi delle versioni di SQL Server non di valutazione sono più elevati rispetto a una macchina virtuale "solo Windows" distribuita da Azure Marketplace. Per confrontare i prezzi, vedere Prezzi di macchine virtuali Windows e Prezzi di Macchine virtuali SQL Server Enterprise.
• È possibile usare solo le versioni di SQL Server supportate da SAP per il software.
• Le regole di confronto dell'istanza di SQL Server installata nelle macchine virtuali offerte in Azure Marketplace non sono quelle che devono essere eseguite nell'istanza di SQL Server per SAP NetWeaver. È 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, necessarie per le 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=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=<local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2
  • <local_admin_account_name> è l'account definito come account amministratore quando si distribuisce la macchina virtuale per la prima volta nella 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 la distribuzione e scoprire perché il comando di configurazione non ha funzionato nel modo previsto. La distribuzione di applicazioni SAP NetWeaver in un'istanza di SQL Server con tabelle codici di SQL Server diverse da quella indicata NON è supportata per le distribuzioni di NetWeaver.

Disponibilità elevata di SQL Server per SAP in Azure

Usando SQL Server nelle distribuzioni IaaS di Azure per SAP, è possibile aggiungere diverse possibilità per distribuire il livello di database a disponibilità elevata. Azure offre contratti di servizio diversi per il tempo di attività di una singola macchina virtuale che usa diverse risorse di archiviazione a blocchi di Azure, una coppia di macchine virtuali distribuite in un set di disponibilità di Azure o una coppia di macchine virtuali distribuite tra zone di disponibilità di Azure. 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 esegue l'istanza di SQL Server attiva. L'altra macchina virtuale esegue l'istanza passiva

Clustering di SQL Server tramite il file server scale-out di Windows o il disco condiviso di Azure

Con Windows Server 2016, Microsoft ha introdotto la funzionalità Spazi di archiviazione diretta. Basato sulla distribuzione degli spazi di archiviazione e sulla distribuzione diretta, il 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 di disponibilità elevata.

Log shipping SQL Server

Una funzionalità di disponibilità elevata è il log shipping di SQL Server. Se le macchine virtuali che partecipano alla configurazione della disponibilità elevata hanno una risoluzione dei nomi funzionante, non c'è alcun problema. La configurazione in Azure non è diversa da qualsiasi configurazione eseguita in locale correlata alla configurazione del log shipping e ai principi relativi al log shipping. I dettagli sul log shipping di SQL Server sono disponibili nell'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. Negli scenari seguenti, tuttavia, i clienti SAP usano il log shipping con successo insieme ad 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 di database in Azure con il sistema di produzione in corso in locale. Al momento del taglio, la produzione viene arrestata e si è verificato che gli ultimi backup del log delle transazioni siano stati trasferiti alla distribuzione del database di Azure. La distribuzione del database di Azure viene quindi aperta per la produzione.

SQL Server AlwaysOn

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

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 i listener del gruppo di disponibilità di SQL Server in Windows Server 2008 R2 e le macchine virtuali Microsoft Azure basate su 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 (operazione eseguita tramite il parametro SAP default.pfl dbs/mss/server. Vedere la nota SAP n. 965908).
• Quando si usa un listener del gruppo di disponibilità, le macchine virtuali del database devono essere connesse a un Load Balancer dedicato. È consigliabile assegnare indirizzi IP statici alle interfacce di rete di tali macchine virtuali nella configurazione di AlwaysOn. La definizione di un indirizzo IP statico è descritta in questo articolo. Gli indirizzi IP statici rispetto al protocollo 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 richiede l'esecuzione di un passaggio manuale per assegnare al cluster un indirizzo IP diverso.
• 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:

• Panoramica sui gruppi di disponibilità Always On di SQL Server in macchine virtuali di Azure
• Configurare un gruppo di disponibilità Always On in macchine virtuali di Azure in aree diverse
• Configurare un servizio di bilanciamento del carico interno per un gruppo di disponibilità Always On in Azure
• Procedure consigliate per la configurazione HADR (SQL Server nelle macchine virtuali di Azure)

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. Il listener DNN elimina la necessità di usare 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 in questo modo nessun servizio di bilanciamento del carico di Azure 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 Transparent Data Encryption (TDE) di SQL Server per la distribuzione dei database SQL Server per SAP 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 database, in esecuzione in locale, a Windows/SQL Server in esecuzione in Azure, è necessario creare il database di destinazione vuoto in SQL Server in anticipo. 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 gestire la distribuzione di TDE come un'attività da svolgere senza carichi di lavoro SAP o con carichi ridotti su un database specifico. Da SQL Server 2016 in poi è 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 queste considerazioni:

• 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. Indica i volumi più distinti (lettere di unità), più thread sono 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 pochi volumi comporta l'esecuzione della crittografia da parte di pochi thread. La crittografia a thread singolo legge gli extent a 64 kB, li crittografa e quindi scrivere un record nel file registro transazioni, indicando 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 è più efficiente quando si crittografa il database 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ò raggiungere un rapporto di compressione di fattore 4.
• Con SQL Server 2016, è stata introdotta una nuova funzionalità che consente anche la compressione dei backup dei database crittografati in modo efficiente. Per i dettagli, vedere questo blog.

Uso di Azure Key Vault

Azure offre il servizio Key Vault per archiviare le chiavi di crittografia. SQL Server offre invece un connettore per usare 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 nelle 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).

Configurazioni minime della distribuzione

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

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

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

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

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

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

Ad esempio, questa configurazione è la configurazione della macchina virtuale di database 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 tutta l'elaborazione finanziaria, 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 di database. Poiché la disponibilità elevata del sistema usa Always On con una replica sincrona in un'altra zona di disponibilità della stessa area di Azure. Un'altra replica asincrona in un'altra area di Azure. Il livello applicazione NetWeaver viene distribuito nelle famiglie di macchine virtuali D(a)/E(a) più recenti.

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 generale, tuttavia, assicurarsi di seguire le raccomandazioni principali di SQL Server in Azure:

1. Usare la versione più recente di SQLServer, ad esempio SQL Server 2022, con i vantaggi più significativi in Azure.
2. Pianificare attentamente l'infrastruttura di 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.
3. Non installare mai il software o inserire file che richiedono la persistenza nell'unità D:\ perché non è gestito. Qualsiasi elemento in questa unità può essere perso al riavvio di Windows o al riavvio della macchina virtuale.
4. Usare la soluzione SQL Server Always On per replicare i dati del database.
5. Usare sempre la risoluzione dei nomi e non fare affidamento sugli indirizzi IP.
6. Quando si usa la funzionalità TDE di SQL Server, applicare le patch più recenti di SQL Server.
7. 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.
8. 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