Pianificare e implementare una distribuzione SAP in Azure

In Azure le organizzazioni possono ottenere le risorse e i servizi cloud necessari senza completare un lungo ciclo di approvvigionamento. Tuttavia, l'esecuzione del carico di lavoro SAP in Azure richiede informazioni sulle opzioni disponibili e un'attenta pianificazione per scegliere i componenti e l'architettura di Azure per alimentare la soluzione.

Azure offre una piattaforma completa per l'esecuzione delle applicazioni SAP. Le offerte PaaS (Infrastructure as a Service) e Platform as a Service (PaaS) di Azure offrono opzioni ottimali per una corretta distribuzione dell'intero panorama aziendale SAP.

Questo articolo integra la documentazione SAP e le note SAP, le origini principali per informazioni su come installare e distribuire software SAP in Azure e in altre piattaforme.

Definizioni

In questo articolo vengono usate le condizioni seguenti:

• Componente SAP: singola applicazione SAP, ad esempio SAP S/4HANA, SAP ECC, SAP BW o SAP Solution Manager. Un componente SAP può essere basato sulle tecnologie ABAP (Advanced Business Application Programming) o Java tradizionali oppure può essere un'applicazione non basata su SAP NetWeaver, ad esempio SAP BusinessObjects.
• Ambiente SAP: raggruppamento logico di più componenti SAP per l'esecuzione di una funzione aziendale, ad esempio sviluppo, controllo della qualità, formazione, ripristino di emergenza o produzione.
• Panorama SAP: l'intero set di asset SAP nel panorama IT di un'organizzazione. Il panorama applicativo SAP include tutti gli ambienti di produzione e non di produzione.
• Sistema SAP: combinazione di un livello DBMS (Database Management System) e di un livello applicazione. Due esempi sono un sistema di sviluppo SAP ERP e un sistema di test SAP BW. In una distribuzione di Azure questi due livelli non possono essere distribuiti tra l'ambiente locale e Azure. Un sistema SAP deve essere distribuito o in locale o in Azure. Tuttavia, è possibile gestire sistemi diversi all'interno di un panorama SAP in Azure o in locale.

Risorse

Il punto di ingresso per la documentazione che descrive come ospitare ed eseguire un carico di lavoro SAP in Azure è Introduzione a SAP in una macchina virtuale di Azure. Nell'articolo sono disponibili collegamenti ad altri articoli che illustrano:

• Specifiche del carico di lavoro SAP per le opzioni di archiviazione, networking e supportate.
• Guide DBMS di SAP per vari sistemi DBMS in Azure.
• Guide alla distribuzione SAP, sia manuali che automatizzate.
• Disponibilità elevata e ripristino di emergenza per il carico di lavoro SAP in Azure
• Integrazione con SAP in Azure con altri servizi e applicazioni di terze parti.

Le note SAP seguenti costituiscono la base delle linee guida di Azure per le distribuzioni SAP:

Numero della nota	Title
1928533	Applicazioni SAP in Azure: dimensioni e prodotti supportati
2015553	SAP in Azure: prerequisiti del supporto
2039619	Applicazioni SAP in Azure che usano Oracle Database
2233094	DB6: applicazioni SAP in Azure che usano IBM Db2 per Linux, UNIX e Windows
1999351	Risoluzione dei problemi del monitoraggio avanzato di Azure per SAP
1409604	Virtualizzazione in Windows: monitoraggio avanzato
2191498	SAP in Linux con Azure: monitoraggio avanzato
2731110	Supporto di appliance virtuali di rete (NVA) per SAP in Azure

Per le limitazioni generali predefinite e massime delle sottoscrizioni e delle risorse di Azure, vedere Sottoscrizione di Azure, limiti, quote e vincoli del servizio.

Scenari

I servizi SAP vengono spesso considerati tra le applicazioni più cruciali in un'azienda. L'architettura e le operazioni delle applicazioni sono complesse ed è importante assicurarsi che vengano soddisfatti tutti i requisiti per la disponibilità e le prestazioni. Un'azienda in genere pensa attentamente a quale provider di servizi cloud scegliere di eseguire tali processi aziendali critici per l'azienda.

Azure è la piattaforma cloud pubblico ideale per le applicazioni SAP e i processi aziendali business critical. Il software SAP più recente, inclusi i sistemi SAP NetWeaver e SAP S/4HANA, può essere ospitato nell'infrastruttura di Azure. Azure offre più di 800 tipi di CPU e macchine virtuali con molti terabyte di memoria.

Per le descrizioni degli scenari supportati e di alcuni scenari non supportati, vedere Scenari supportati da SAP in macchine virtuali di Azure. Controllare questi scenari e le condizioni indicate come non supportate durante la pianificazione dell'architettura da distribuire in Azure.

Per distribuire correttamente i sistemi SAP in Azure IaaS o IaaS in generale, è importante comprendere le differenze significative tra le offerte di cloud privati tradizionali e le offerte IaaS. Un host tradizionale o un outsourcer adatta l'infrastruttura (rete, archiviazione e tipo di server) al carico di lavoro che un cliente vuole ospitare. In una distribuzione IaaS, è responsabilità del cliente o del partner valutare il carico di lavoro potenziale e scegliere i componenti di Azure corretti di macchine virtuali, archiviazione e rete.

Per raccogliere dati per la pianificazione della distribuzione in Azure, è importante:

• Determinare quali prodotti e versioni SAP sono supportati in Azure.
• Valutare se i rilasci del sistema operativo che si prevede di usare sono supportati con le macchine virtuali di Azure scelte per i prodotti SAP.
• Determinare quali versioni di DBMS in macchine virtuali specifiche sono supportate per i prodotti SAP.
• Valutare se è necessario aggiornare o aggiornare il panorama applicativo SAP per allinearsi al sistema operativo e alle versioni DBMS necessarie per ottenere una configurazione supportata.
• Valutare se è necessario andare a sistemi operativi diversi per eseguire la distribuzione in Azure.

Per informazioni dettagliate sui componenti SAP in Azure supportati, sulle unità dell'infrastruttura di Azure e sulle versioni del sistema operativo e del sistema di gestione di database correlate, vedere Software SAP supportato per le distribuzioni di Azure. Le conoscenze acquisite dalla valutazione del supporto e delle dipendenze tra le versioni SAP, le versioni del sistema operativo e le versioni DBMS hanno un impatto significativo sugli sforzi per spostare i sistemi SAP in Azure. Si apprenderà se sono coinvolte attività di preparazione significative, ad esempio se è necessario aggiornare la versione SAP o andare a un sistema operativo diverso.

Primi passaggi per pianificare una distribuzione

Il primo passaggio della pianificazione della distribuzione non consiste nell'cercare le macchine virtuali disponibili per l'esecuzione di applicazioni SAP.

I primi passaggi per pianificare una distribuzione sono collaborare con i team di conformità e sicurezza dell'organizzazione per determinare le condizioni limite per la distribuzione del tipo di carico di lavoro SAP o del processo aziendale in un cloud pubblico. Il processo può richiedere molto tempo, ma è fondamentale completarlo.

Se l'organizzazione ha già distribuito software in Azure, il processo potrebbe essere semplice. Se la società affronta questa procedura per la prima volta, è possibile che sia necessario dedicare più tempo per stabilire le condizioni di limite, le condizioni di sicurezza e l'architettura Enterprise che consentono di ospitare in un cloud pubblico determinati dati SAP e processi aziendali SAP.

Pianificare la conformità

Per un elenco delle offerte di conformità Microsoft che consentono di pianificare le esigenze di conformità, vedere Offerte di conformità Microsoft.

Pianificare la protezione

Per informazioni sui problemi di sicurezza specifici di SAP, ad esempio la crittografia dei dati per i dati inattivi o altre crittografia in un servizio di Azure, vedere Panoramica della crittografia di Azure e Sicurezza per il panorama applicativo SAP.

Organizzare le risorse di Azure

Insieme alla verifica della sicurezza e della conformità, se non è ancora stata eseguita questa attività, pianificare come organizzare le risorse di Azure. Il processo include decisioni relative a:

• Convenzione di denominazione usata per ogni risorsa di Azure, ad esempio per le macchine virtuali e i gruppi di risorse.
• Progettazione di sottoscrizioni e gruppi di gestione per il carico di lavoro SAP, ad esempio se è necessario creare più sottoscrizioni per ogni carico di lavoro, per livello di distribuzione o per ogni business unit.
• Utilizzo a livello aziendale di Criteri di Azure per sottoscrizioni e gruppi di gestione.

Per prendere le decisioni appropriate, molti dettagli dell'architettura aziendale sono descritti in Azure Cloud Adoption Framework.

Non sottovalutare la fase iniziale del progetto durante la pianificazione. Solo quando sono presenti contratti e regole per la conformità, la sicurezza e l'organizzazione delle risorse di Azure, è consigliabile pianificare la distribuzione.

I passaggi successivi sono la pianificazione della posizione geografica e l'architettura di rete distribuita in Azure.

Aree geografiche di Azure

I servizi di Azure sono disponibili in aree di Azure separate. Un'area di Azure è una raccolta di data center. I data center contengono l'hardware e l'infrastruttura che ospitano ed eseguono i servizi di Azure disponibili nell'area. Questa infrastruttura include un numero elevato di nodi che fungono da nodi di calcolo o da nodi di archiviazione oppure eseguono funzionalità di rete.

Per un elenco delle aree di Azure, vedere Aree geografiche di Azure. Per una mappa interattiva, vedere Infrastruttura globale di Azure.

Non tutte le aree di Azure offrono gli stessi servizi. A seconda del prodotto SAP che si vuole eseguire, dei requisiti di dimensionamento e del sistema operativo e del sistema operativo DBMS necessari, è possibile che una determinata area non offra i tipi di macchina virtuale necessari per lo scenario. Ad esempio, se si esegue SAP HANA, sono in genere necessarie macchine virtuali delle varie famiglie di macchine virtuali serie M. Queste famiglie di macchine virtuali vengono distribuite solo in un subset di aree di Azure.

Quando si inizia a pianificare e considerare le aree da scegliere come area primaria e infine l'area secondaria, è necessario verificare se i servizi necessari per gli scenari sono disponibili nelle aree che si stanno valutando. È possibile apprendere esattamente quali tipi di macchine virtuali, tipi di archiviazione di Azure e altri servizi di Azure sono disponibili in ogni area in Prodotti disponibili in base all'area.

Aree abbinate di Azure

In un'area abbinata di Azure la replica di determinati dati è abilitata per impostazione predefinita tra le due aree. Per altre informazioni, vedere Replica tra aree in Azure: continuità aziendale e ripristino di emergenza.

La replica dei dati in una coppia di aree è associata a tipi di archiviazione di Azure che è possibile configurare per la replica in un'area abbinata. Per informazioni dettagliate, vedere Ridondanza dell'archiviazione in un'area secondaria.

I tipi di archiviazione che supportano la replica dei dati dell'area abbinata sono tipi di archiviazione non adatti per i componenti SAP e un carico di lavoro DBMS. L'usabilità della replica di archiviazione di Azure è limitata all'archiviazione BLOB di Azure (a scopo di backup), alle condivisioni file e ai volumi e ad altri scenari di archiviazione a latenza elevata.

Quando si controllano le aree abbinate e i servizi da usare nelle aree primarie o secondarie, è possibile che i servizi o i tipi di VM di Azure che si intende usare nell'area primaria non siano disponibili nell'area abbinata che si desidera usare come area secondaria. In alternativa, è possibile determinare che un'area abbinata di Azure non è accettabile per lo scenario a causa di motivi di conformità dei dati. Per questi scenari, è necessario usare un'area non abbinata come area secondaria o di ripristino di emergenza ed è necessario configurare manualmente una parte della replica dei dati.

Zone di disponibilità

Molte aree di Azure usano zone di disponibilità per separare fisicamente le posizioni all'interno di un'area di Azure. Ogni zona di disponibilità è costituita da uno o più Data Center dotati di impianti indipendenti per l'energia, il raffreddamento e il networking. Un esempio di uso di una zona di disponibilità per migliorare la resilienza consiste nella distribuzione di due macchine virtuali in due zone di disponibilità separate in Azure. Un altro esempio consiste nell'implementare un framework a disponibilità elevata per il sistema DBMS SAP in una zona di disponibilità e distribuire SAP (A)SCS in un'altra zona di disponibilità, in modo da ottenere il miglior contratto di servizio in Azure.

Per altre informazioni sui contratti di servizio delle macchine virtuali in Azure, vedere la versione più recente dei contratti di servizio delle macchine virtuali. Poiché le aree di Azure sviluppano ed estendono rapidamente, la topologia delle aree di Azure, il numero di data center fisici, la distanza tra i data center e la distanza tra le zone di disponibilità di Azure si evolve. La latenza di rete cambia man mano che cambia l'infrastruttura.

Seguire le indicazioni riportate nelle configurazioni del carico di lavoro SAP con le zone di disponibilità di Azure quando si sceglie un'area con zone di disponibilità. Determinare anche quale modello di distribuzione di zona è più adatto per i requisiti, l'area scelta e il carico di lavoro.

Domini di errore

I domini di errore rappresentano un'unità fisica di errore. Un dominio di errore è strettamente correlato all'infrastruttura fisica contenuta nei data center. Anche se un pannello fisico o un rack può essere considerato un dominio di errore, non esiste un mapping uno-a-uno diretto tra un elemento di calcolo fisico e un dominio di errore.

Quando si distribuiscono più macchine virtuali come parte di un sistema SAP, è possibile influenzare indirettamente il controller di infrastruttura di Azure per distribuire le macchine virtuali in domini di errore diversi, in modo da poter soddisfare i requisiti per i contratti di servizio di disponibilità. Tuttavia, l'utente non ha controllo diretto sulla distribuzione di domini di errore in un'unità di scala di Azure (una raccolta di centinaia di nodi di calcolo o di nodi di archiviazione e di risorse di networking), o sull'assegnazione di macchine virtuali a un dominio di errore specifico. Per fare in modo che il controller di infrastruttura di Azure distribuisca un set di macchine virtuali in diversi domini di errore, è necessario assegnare un set di disponibilità di Azure alle macchine virtuali durante la fase di distribuzione. Per altre informazioni, vedere Set di disponibilità.

Domini di aggiornamento

I domini di aggiornamento rappresentano un'unità logica che imposta la modalità di aggiornamento di una macchina virtuale in un sistema SAP costituito da più macchine virtuali. Quando si verifica un aggiornamento della piattaforma, Azure esegue il processo di aggiornamento di questi domini di aggiornamento uno alla sola. Suddividendo le macchine virtuali in diversi domini di aggiornamento durante la fase di distribuzione, è possibile proteggere il sistema SAP da potenziali tempi di inattività. Analogamente ai domini di errore, un'unità di scala di Azure viene divisa in più domini di aggiornamento. Per fare in modo che il controller di infrastruttura di Azure distribuisca un set di macchine virtuali in diversi domini di aggiornamento, è necessario assegnare un set di disponibilità di Azure alle VM durante la fase di distribuzione. Per altre informazioni, vedere Set di disponibilità.

Set di disponibilità

Le macchine virtuali di Azure in un set di disponibilità di Azure verranno distribuite dal controller di infrastruttura di Azure in diversi domini di errore. La distribuzione su domini di errore diversi consiste nel impedire l'arresto di tutte le macchine virtuali di un sistema SAP durante la manutenzione dell'infrastruttura o se si verifica un errore in un dominio di errore. Per impostazione predefinita, le macchine virtuali non fanno parte di un set di disponibilità. È possibile aggiungere una macchina virtuale in un set di disponibilità solo in fase di distribuzione o quando una macchina virtuale viene ridistribuito.

Per altre informazioni sui set di disponibilità di Azure e sul modo in cui i set di disponibilità sono correlati ai domini di errore, vedere Set di disponibilità di Azure.

Quando si definiscono i set di disponibilità e si prova a combinare macchine virtuali di famiglie diverse in un set di disponibilità, potrebbero verificarsi problemi che impediscono di includere un determinato tipo di macchina virtuale in un set di disponibilità. Il motivo è che il set di disponibilità è associato a un'unità di scala che contiene un determinato tipo di host di calcolo Un tipo specifico di host di calcolo può essere eseguito solo in determinati tipi di famiglie di macchine virtuali.

Ad esempio, si crea un set di disponibilità e si distribuisce la prima macchina virtuale nel set di disponibilità. La prima macchina virtuale aggiunta al set di disponibilità è nella famiglia di macchine virtuali Edsv5. Quando si tenta di distribuire una seconda macchina virtuale, una macchina virtuale nella famiglia M ha esito negativo. Il motivo è che le macchine virtuali della famiglia Edsv5 non vengono eseguite nello stesso hardware host delle macchine virtuali della famiglia M.

Lo stesso problema può verificarsi se si ridimensionano le macchine virtuali. Se si tenta di spostare una macchina virtuale dalla famiglia Edsv5 e in un tipo di macchina virtuale incluso nella famiglia M, la distribuzione ha esito negativo. Nel caso di ridimensionamento in una famiglia di macchine virtuali che non può essere ospitata nello stesso hardware host, è necessario arrestare tutte le macchine virtuali del set di disponibilità e ridimensionarle tutte per poterle eseguire nell'altro tipo di computer host. Per informazioni sui contratti di servizio delle macchine virtuali distribuite in un set di disponibilità, vedere Contratti di servizio delle macchine virtuali.

Set di scalabilità di macchine virtuali con orchestrazione flessibile

I set di scalabilità di macchine virtuali con orchestrazione flessibile offrono un raggruppamento logico di macchine virtuali gestite dalla piattaforma. È possibile creare un set di scalabilità all'interno dell'area o estenderlo tra le zone di disponibilità. Durante la creazione, il set di scalabilità flessibile all'interno di un'area con platformFaultDomainCount>1 (FD>1), le macchine virtuali distribuite nel set di scalabilità verranno distribuite tra il numero specificato di domini di errore nella stessa area. D'altra parte, la creazione del set di scalabilità flessibile tra zone di disponibilità con platformFaultDomainCount=1 (FD=1) distribuirà le macchine virtuali nella zona specificata e il set di scalabilità distribuirà anche le macchine virtuali in domini di errore diversi all'interno della zona per un'operazione ottimale.

Per il carico di lavoro SAP è supportato solo un set di scalabilità flessibile con FD=1. Il vantaggio dell'uso di set di scalabilità flessibili con FD=1 per la distribuzione tra zone, invece della distribuzione tradizionale della zona di disponibilità consiste nel fatto che le macchine virtuali distribuite con il set di scalabilità verranno distribuite tra domini di errore diversi all'interno della zona in modo ottimale. Per altre informazioni sulla distribuzione del carico di lavoro SAP con set di scalabilità, vedere la guida alla distribuzione flessibile della scalabilità di macchine virtuali.

Quando si distribuisce un carico di lavoro SAP a disponibilità elevata in Azure, è importante prendere in considerazione i vari tipi di distribuzione disponibili e come possono essere applicati in aree di Azure diverse, ad esempio tra zone, in una singola zona o in un'area senza zone. Per altre informazioni, vedere Opzioni di distribuzione a disponibilità elevata per il carico di lavoro SAP.

Gruppi di selezione host di prossimità

La latenza di rete tra singole macchine virtuali SAP può avere implicazioni significative per le prestazioni. Il tempo di round trip di rete tra server applicazioni SAP e DBMS può avere un impatto significativo sulle applicazioni aziendali. In modo ottimale, tutti gli elementi di calcolo che eseguono le macchine virtuali SAP si trovano il più possibile. Questa opzione non è possibile in ogni combinazione e Azure potrebbe non sapere quali macchine virtuali mantenere insieme. Nella maggior parte delle situazioni e delle aree, il posizionamento predefinito soddisfa i requisiti di latenza del round trip di rete.

Quando il posizionamento predefinito non soddisfa i requisiti di round trip di rete all'interno di un sistema SAP, i gruppi di posizionamento di prossimità possono soddisfare questa esigenza. È possibile usare i gruppi di posizionamento di prossimità con i vincoli di posizione dell'area di Azure, della zona di disponibilità e del set di disponibilità per aumentare la resilienza. Con un gruppo di posizionamento di prossimità, è possibile combinare sia la zona di disponibilità che il set di disponibilità durante l'impostazione di domini di aggiornamento e di errore diversi. Un gruppo di posizionamento di prossimità deve contenere solo un singolo sistema SAP.

Anche se la distribuzione in un gruppo di posizionamento di prossimità può comportare la posizione più ottimizzata per la latenza, la distribuzione tramite un gruppo di posizionamento di prossimità presenta anche svantaggi. Alcune famiglie di macchine virtuali non possono essere combinate in un gruppo di posizionamento di prossimità o si potrebbero riscontrare problemi se si esegue il ridimensionamento tra famiglie di macchine virtuali. I vincoli delle famiglie di macchine virtuali, delle aree e delle zone di disponibilità potrebbero non supportare la condivisione. Per informazioni dettagliate sui vantaggi e sulle potenziali sfide dell'uso di un gruppo di posizionamento di prossimità, vedere Scenari di gruppo di posizionamento di prossimità.

Le macchine virtuali che non usano gruppi di posizionamento di prossimità devono essere il metodo di distribuzione predefinito nella maggior parte dei casi per i sistemi SAP. Questo valore predefinito è particolarmente vero per le distribuzioni di zona (una singola zona di disponibilità) e tra zone (VM distribuite tra due zone di disponibilità) di un sistema SAP. L'uso dei gruppi di posizionamento di prossimità deve essere limitato ai sistemi SAP e alle aree di Azure, se necessario solo per motivi di prestazioni.

Rete di Azure

Azure dispone di un'infrastruttura di rete mappata a tutti gli scenari che è possibile implementare in una distribuzione SAP. In Azure sono disponibili le funzionalità seguenti:

• Accesso ai servizi di Azure e accesso a porte specifiche nelle macchine virtuali usate dalle applicazioni.
• Accesso diretto alle macchine virtuali tramite Secure Shell (SSH) o Desktop remoto Windows (RDP) per la gestione e l'amministrazione.
• Comunicazione interna e risoluzione dei nomi tra macchine virtuali e servizi di Azure.
• Connettività locale tra una rete locale e reti di Azure.
• Comunicazione tra servizi distribuiti in aree di Azure diverse.

Per informazioni dettagliate sul networking vedere Rete virtuale di Azure.

La progettazione del networking è in genere la prima attività tecnica che si svolge quando si esegue la distribuzione in Azure. Il supporto di un'architettura aziendale centrale come SAP fa spesso parte dei requisiti di networking generali. Nella fase di pianificazione è consigliabile documentare l'architettura di networking proposta nel modo più dettagliato possibile. Se si apporta una modifica in un secondo momento, ad esempio modificando un indirizzo di rete della subnet, potrebbe essere necessario spostare o eliminare le risorse distribuite.

Reti virtuali di Azure

Una rete virtuale è un blocco costitutivo fondamentale per una rete privata in Azure. È possibile definire l'intervallo di indirizzi della rete e separare l'intervallo in subnet di rete. Una subnet di rete può essere disponibile per l'uso di una macchina virtuale SAP oppure può essere dedicata a un servizio o a uno scopo specifico. Alcuni servizi di Azure, ad esempio rete virtuale di Azure e gateway applicazione di Azure, richiedono una subnet dedicata.

Una rete virtuale funge da limite di rete. Parte della progettazione necessaria quando si pianifica la distribuzione consiste nel definire la rete virtuale, le subnet e gli intervalli di indirizzi di rete privata. Non è possibile modificare l'assegnazione di rete virtuale per risorse come schede di interfaccia di rete (NIC) per le macchine virtuali dopo la distribuzione delle macchine virtuali. L'esecuzione di una modifica a una rete virtuale o a un intervallo di indirizzi di subnet potrebbe richiedere lo spostamento di tutte le risorse distribuite in una subnet diversa.

La progettazione di rete deve soddisfare diversi requisiti per la distribuzione SAP:

• Nessuna appliance virtuale di rete, ad esempio un firewall, viene inserita nel percorso di comunicazione tra l'applicazione SAP e il livello DBMS dei prodotti SAP tramite il kernel SAP, ad esempio S/4HANA o SAP NetWeaver.
• Le restrizioni di routing di rete vengono applicate dai gruppi di sicurezza di rete (NSG) a livello di subnet. Raggruppare gli indirizzi IP delle macchine virtuali nei gruppi di sicurezza delle applicazioni (ASG) gestiti nelle regole del gruppo di sicurezza di rete e fornire raggruppamenti di ruoli, livelli e SID delle autorizzazioni.
• Le macchine virtuali di database e applicazioni SAP vengono eseguite nella stessa rete virtuale, all'interno delle stesse subnet o diverse di una singola rete virtuale. Usare subnet diverse per le macchine virtuali di applicazioni e database. In alternativa, usare applicazioni dedicate e asg DBMS per raggruppare le regole applicabili a ogni tipo di carico di lavoro all'interno della stessa subnet.
• Il networking accelerato è abilitato in tutte le schede di rete di tutte le macchine virtuali per i carichi di lavoro SAP, dove tecnicamente possibile.
• Garantire l'accesso sicuro per la dipendenza dai servizi centrali, tra cui per la risoluzione dei nomi (DNS), la gestione delle identità (domini di Active Directory di Windows Server/ID Microsoft Entra) e l'accesso amministrativo.
• Fornire l'accesso a e da endpoint pubblici, in base alle esigenze. Gli esempi includono per la gestione di Azure per le operazioni di ClusterLabs Pacemaker in disponibilità elevata o per i servizi di Azure come Backup di Azure.
• Usare più schede di interfaccia di rete solo se sono necessarie per creare subnet designate con route e regole del gruppo di sicurezza di rete.

Per esempi di architettura di rete per la distribuzione SAP, vedere gli articoli seguenti:

• SAP S/4HANA on Linux in Azure
• SAP NetWeaver in Windows in Azure
• Comunicazione Internet in ingresso e in uscita per SAP in Azure

Considerazioni sulla rete virtuale

Alcune configurazioni di networking virtuale hanno considerazioni specifiche da tenere presenti.

• La configurazione di appliance virtuali di rete nel percorso di comunicazione tra il livello dell'applicazione SAP e il livello DBMS dei componenti SAP tramite il kernel SAP, ad esempio S/4HANA o SAP NetWeaver, non è supportato.

  Le appliance virtuali di rete nei percorsi di comunicazione possono facilmente raddoppiare la latenza di rete tra due partner di comunicazione. Possono anche limitare la velocità effettiva nei percorsi critici tra il livello dell'applicazione SAP e il livello DBMS. In alcuni scenari, le appliance virtuali di rete possono causare errori dei cluster Linux Pacemaker.

  Il percorso di comunicazione tra il livello dell'applicazione SAP e il livello DBMS deve essere diretto. La restrizione non include le regole del Gruppo di scienze applicate e del gruppo di sicurezza di rete se le regole del gruppo di scienze applicate e del Gruppo di sicurezza di rete consentono un percorso di comunicazione diretta.

  Altri scenari in cui le appliance virtuali di rete non sono supportate sono:

  • Percorsi di comunicazione tra macchine virtuali di Azure che rappresentano i nodi del cluster Pacemaker di Linux e i dispositivi SBD, come descritto in Disponibilità elevata per SAP NetWeaver su macchine virtuali di Azure in SUSE Linux Enterprise Server per applicazioni SAP.
  • Percorsi di comunicazione tra macchine virtuali di Azure e una condivisione file scale-out di Windows Server configurati come descritto in Clustering di un'istanza ASCS/SCS di SAP in un cluster di failover Windows tramite una condivisione file in Azure.

• La separazione del livello applicazione SAP e del livello DBMS in reti virtuali di Azure diverse non è supportata. È consigliabile separare il livello dell'applicazione SAP e il livello DBMS usando subnet all'interno della stessa rete virtuale di Azure, anziché usare reti virtuali di Azure diverse.

  Se si configura uno scenario non supportato che separa due livelli di sistema SAP in reti virtuali differenti, è necessario eseguire il peering delle due reti virtuali.

  Il traffico di rete tra due reti virtuali di Azure connesse tramite peering è soggetto a costi di trasferimento. Ogni giorno, grandi volumi di dati dell'ordine di molti terabyte vengono scambiati tra il livello dell'applicazione SAP e il livello DBMS. Si può incorrere in costi sostanziali se il livello dell'applicazione SAP e il livello DBMS sono separati tra due reti virtuali di Azure connesse tramite peering.

Risoluzione dei nomi e servizi di dominio

La risoluzione del nome host nell'indirizzo IP tramite DNS è spesso un elemento fondamentale per il networking SAP. Sono disponibili molte opzioni per configurare il nome e la risoluzione IP in Azure.

Spesso un'azienda ha una soluzione DNS centrale che fa parte dell'architettura complessiva. Diverse opzioni per implementare la risoluzione dei nomi in Azure in modo nativo, invece di configurare i propri server DNS, sono descritte in Risoluzione dei nomi per le risorse nelle reti virtuali di Azure.

Come per i servizi DNS, potrebbe essere necessario che Windows Server Active Directory sia accessibile dalle macchine virtuali o dai servizi SAP.

Assegnazione indirizzi IP

Un indirizzo IP per una scheda di interfaccia di rete rimane richiesto e usato per tutta l'esistenza della scheda di interfaccia di rete di una macchina virtuale. La regola si applica sia all'assegnazione IP dinamica che statica. Rimane vero se la macchina virtuale è in esecuzione o è arrestata. L'assegnazione ip dinamica viene rilasciata se la scheda di interfaccia di rete viene eliminata, se la subnet cambia o se il metodo di allocazione viene modificato in statico.

È possibile assegnare indirizzi IP fissi a macchine virtuali in una rete virtuale di Azure. Gli indirizzi IP vengono spesso riassegnati per i sistemi SAP che dipendono da server DNS esterni e voci statiche. L'indirizzo IP rimane assegnato, fino a quando non viene eliminata la macchina virtuale e la relativa scheda di interfaccia di rete o fino a quando l'indirizzo IP non viene assegnato. È necessario tenere conto del numero complessivo di macchine virtuali (in esecuzione e arrestate) quando si definisce l'intervallo di indirizzi IP per la rete virtuale.

Per altre informazioni, vedere Creare una macchina virtuale con un indirizzo IP privato statico.

Indirizzi IP secondari per la virtualizzazione dei nomi host SAP

A ogni scheda di interfaccia di rete della macchina virtuale di Azure possono essere assegnati più indirizzi IP. È possibile usare un indirizzo IP secondario per un nome host virtuale SAP, mappato a un record DNS A o a un record PTR DNS. È necessario assegnare un indirizzo IP secondario alla configurazione IP della scheda di interfaccia di rete di Azure. È necessario configurare anche un indirizzo IP secondario all'interno del sistema operativo in modo statico perché gli indirizzi IP secondari spesso non vengono assegnati tramite DHCP. Ogni indirizzo IP secondario deve trovarsi dalla stessa subnet a cui è associata la scheda di interfaccia di rete. È possibile aggiungere e rimuovere un indirizzo IP secondario da una scheda di interfaccia di rete di Azure senza arrestare o deallocare la macchina virtuale. Per aggiungere o rimuovere l'indirizzo IP primario di una scheda di interfaccia di rete, è necessario deallocare la macchina virtuale.

Il servizio di bilanciamento del carico di Azure viene usato dalle architetture SAP a disponibilità elevata con cluster Pacemaker. In questo scenario, il servizio di bilanciamento del carico abilita i nomi host virtuali SAP. Per indicazioni generali sull'uso dei nomi host virtuali, vedere la nota SAP 962955.

Azure Load Balancer con macchine virtuali che eseguono SAP

Un servizio di bilanciamento del carico viene in genere usato nelle architetture a disponibilità elevata per fornire indirizzi IP mobili tra nodi del cluster attivo e passivo. È anche possibile usare un servizio di bilanciamento del carico per una singola macchina virtuale per contenere un indirizzo IP virtuale per un nome host virtuale SAP. L'uso di un servizio di bilanciamento del carico per una singola macchina virtuale è un'alternativa all'uso di un indirizzo IP secondario in una scheda di interfaccia di rete o all'uso di più schede di interfaccia di rete nella stessa subnet.

Il servizio di bilanciamento del carico standard modifica il percorso di accesso in uscita predefinito perché l'architettura è protetta per impostazione predefinita. Le macchine virtuali che si trovano dietro un servizio di bilanciamento del carico standard potrebbero non essere più in grado di raggiungere gli stessi endpoint pubblici. Alcuni esempi sono un endpoint per un repository di aggiornamento del sistema operativo o un endpoint pubblico dei servizi di Azure. Per le opzioni per fornire la connettività in uscita, vedere Connettività degli endpoint pubblici per le macchine virtuali usando il servizio di bilanciamento del carico standard di Azure.

Più schede di interfaccia di rete virtuale per macchina virtuale

È possibile definire più schede di interfaccia di rete virtuale (vNIC) per una macchina virtuale di Azure, con ogni scheda di interfaccia di rete virtuale assegnata a qualsiasi subnet nella stessa rete virtuale della scheda di interfaccia di rete virtuale primaria. Con la possibilità di avere più vNIC, è possibile iniziare a configurare la separazione del traffico di rete, se necessario. Ad esempio, il traffico client viene instradato attraverso la scheda di interfaccia di rete virtuale primaria e il traffico di amministrazione o back-end viene instradato attraverso una seconda scheda di interfaccia di rete virtuale. A seconda del sistema operativo e dell'immagine usata, potrebbe essere necessario configurare le route di traffico per le schede di interfaccia di rete all'interno del sistema operativo per il routing corretto.

Il tipo e le dimensioni di una macchina virtuale determinano il numero di vNIC a cui può essere assegnata una macchina virtuale. Per informazioni sulle funzionalità e sulle restrizioni, vedere Assegnare più indirizzi IP alle macchine virtuali usando il portale di Azure.

L'aggiunta di vNIC a una macchina virtuale non aumenta la larghezza di banda di rete disponibile. Tutte le interfacce di rete condividono la stessa larghezza di banda. È consigliabile usare più schede di interfaccia di rete solo se le macchine virtuali devono accedere a subnet private. È consigliabile un modello di progettazione che si basa sulle funzionalità del gruppo di sicurezza di rete e che semplifica i requisiti di rete e subnet. La progettazione deve usare il minor numero possibile di interfacce di rete e, in modo ottimale, solo una. Un'eccezione è lo scale-out di HANA, in cui è necessaria una scheda di interfaccia di rete virtuale secondaria per la rete interna HANA.

Rete accelerata

Per ridurre ulteriormente la latenza di rete tra macchine virtuali di Azure, è consigliabile verificare che il networking accelerato di Azure sia abilitata in ogni macchina virtuale che esegue un carico di lavoro SAP. Anche se il networking accelerato è abilitato per impostazione predefinita per le nuove macchine virtuali, in base all'elenco di controllo per la distribuzione, è necessario verificare lo stato. I vantaggi del networking accelerato sono notevolmente migliorati in termini di prestazioni e latenze di networking. Usarla quando si distribuiscono macchine virtuali di Azure per carichi di lavoro SAP in tutte le macchine virtuali supportate, in particolare per il livello dell'applicazione SAP e il livello DBMS di SAP. La documentazione collegata contiene le dipendenze del supporto per le versioni del sistema operativo e le istanze di VM.

Connettività locale

La distribuzione SAP in Azure presuppone che sia disponibile un'architettura di rete centrale e a livello aziendale e un hub di comunicazione per abilitare la connettività locale. La connettività di rete locale è essenziale per consentire agli utenti e alle applicazioni di accedere al panorama SAP in Azure per accedere ad altri servizi dell'organizzazione centrale, ad esempio DNS centrale, dominio e sicurezza e infrastruttura di gestione delle patch.

Sono disponibili molte opzioni per fornire connettività locale per la distribuzione di SAP in Azure. La distribuzione di networking più spesso è una topologia di rete hub-spoke o un'estensione della topologia hub-spoke, una rete WAN virtuale globale.

Per le distribuzioni SAP locali, è consigliabile usare una connessione privata tramite Azure ExpressRoute. Per carichi di lavoro SAP più piccoli, aree remote o uffici più piccoli, è disponibile la connettività VPN locale. L'uso di ExpressRoute con una connessione VPN da sito a sito come percorso di failover è una possibile combinazione di entrambi i servizi.

Connettività Internet in uscita e in ingresso

Il panorama SAP richiede la connettività a Internet, indipendentemente dal fatto che riceva gli aggiornamenti del repository del sistema operativo, stabilire una connessione alle applicazioni SaaS SAP negli endpoint pubblici o accedere a un servizio di Azure tramite l'endpoint pubblico. Analogamente, potrebbe essere necessario fornire l'accesso ai client alle applicazioni SAP Fiori, con gli utenti Internet che accedono ai servizi forniti dall'ambiente SAP. L'architettura di rete SAP richiede di pianificare il percorso verso Internet e per le richieste in ingresso.

Proteggere la rete virtuale usando le regole del gruppo di sicurezza di rete, usando i tag del servizio di rete per i servizi noti e stabilendo il routing e l'indirizzamento IP al firewall o ad altre appliance virtuali di rete. Tutte queste attività o considerazioni fanno parte dell'architettura. Le risorse nelle reti private devono essere protette da firewall di rete di livello 4 e di livello 7.

I percorsi di comunicazione con Internet sono l'obiettivo di un'architettura delle procedure consigliate.

Macchine virtuali di Azure per carichi di lavoro SAP

Alcune famiglie di macchine virtuali di Azure sono particolarmente adatte per i carichi di lavoro SAP e altre in particolare per un carico di lavoro SAP HANA. Il modo per trovare il tipo di macchina virtuale corretto e la relativa funzionalità per supportare il carico di lavoro SAP è descritto in Che software SAP è supportato per le distribuzioni di Azure. Nota SAP 1928533 elenca anche tutte le macchine virtuali di Azure certificate e le relative funzionalità di prestazioni misurate dal benchmark e dalle limitazioni SAP Application Performance Standard (SAPS), se applicabili. I tipi di macchina virtuale certificati per un carico di lavoro SAP non usano il provisioning eccessivo per le risorse di CPU e memoria.

Oltre a esaminare solo la selezione dei tipi di macchina virtuale supportati, è necessario verificare se tali tipi di macchine virtuali sono disponibili in un'area specifica in base ai prodotti disponibili in base all'area. Almeno quanto importante è determinare se le funzionalità seguenti per una macchina virtuale rientrano nello scenario:

• CPU e risorse di memoria
• Larghezza di banda Operazioni di input/output al secondo (IOPS)
• Funzionalità di rete
• Il numero di dischi che è possibile collegare
• Possibilità di usare determinati tipi di archiviazione di Azure

Per ottenere queste informazioni per una famiglia e un tipo DI FM specifici, vedere Dimensioni per le macchine virtuali in Azure.

Modelli di determinazione dei prezzi per le macchine virtuali di Azure

Per un modello di determinazione prezzi della macchina virtuale, è possibile scegliere l'opzione che si preferisce usare:

• Un modello di prezzi con pagamento in base al consumo
• Piano di risparmio o riservato di un anno
• Piano di risparmio o riservato di tre anni
• Un modello di determinazione prezzi spot

Per ottenere informazioni dettagliate sui prezzi delle macchine virtuali per diversi servizi, sistemi operativi e aree di Azure, vedere Prezzi delle macchine virtuali.

Per informazioni sui prezzi e sulla flessibilità dei piani di risparmio di un anno e di tre anni e delle istanze riservate, vedere questi articoli:

• Quali sono i piani di risparmio di Azure per il calcolo?
• Informazioni sulle prenotazioni di Azure
• Flessibilità di dimensioni delle macchine virtuali con le istanze di macchina virtuale riservate
• Come viene applicato lo sconto per la prenotazione di Azure alle macchine virtuali

Per altre informazioni sui prezzi spot, vedere Azure Spot Virtual Machines.

I prezzi per lo stesso tipo di macchina virtuale possono variare tra le aree di Azure. Alcuni clienti traggono vantaggio dalla distribuzione in un'area di Azure meno costosa, quindi le informazioni sui prezzi in base all'area possono essere utili durante la pianificazione.

Azure offre anche la possibilità di usare un host dedicato. L'uso di un host dedicato offre un maggiore controllo dei cicli di applicazione di patch per i servizi di Azure. È possibile pianificare l'applicazione di patch per supportare i propri cicli e pianificazioni. Questa offerta è specificamente per i clienti che hanno un carico di lavoro che non segue il normale ciclo di un carico di lavoro. Per altre informazioni, vedere Host dedicati di Azure.

L'uso di un host dedicato di Azure è supportato per un carico di lavoro SAP. Diversi clienti SAP che vogliono avere maggiore controllo sull'applicazione di patch dell'infrastruttura e sui piani di manutenzione usano host dedicati di Azure. Per altre informazioni su come Microsoft gestisce e applica patch all'infrastruttura di Azure che ospita le macchine virtuali, vedere Manutenzione per le macchine virtuali in Azure.

Sistema operativo per le macchine virtuali

Quando si distribuiscono nuove macchine virtuali per un panorama SAP in Azure, per installare o eseguire la migrazione di un sistema SAP, è importante scegliere il sistema operativo corretto per il carico di lavoro. Azure offre una vasta gamma di immagini del sistema operativo per Linux e Windows e molte opzioni adatte per i sistemi SAP. È anche possibile creare o caricare immagini personalizzate dall'ambiente locale oppure utilizzare o generalizzare dalle raccolte di immagini.

Per informazioni dettagliate e informazioni sulle opzioni disponibili:

• Trovare immagini di Azure Marketplace usando l'interfaccia della riga di comando di Azure o Azure PowerShell.
• Creare immagini personalizzate per Linux o Windows.
• Usare Image Builder per macchine virtuali di Azure.

Pianificare un'infrastruttura di aggiornamento del sistema operativo e le relative dipendenze per il carico di lavoro SAP, se necessario. Prendere in considerazione l'uso di un ambiente di gestione temporanea del repository per mantenere sincronizzati tutti i livelli di un ambiente SAP (sandbox, sviluppo, preproduzione e produzione) usando le stesse versioni di patch e aggiornamenti durante il periodo di tempo di aggiornamento.

Macchine virtuali di prima e seconda generazione

In Azure è possibile distribuire una macchina virtuale come generazione 1 o generazione 2. Il supporto per le macchine virtuali di seconda generazione in Azure elenca le famiglie di macchine virtuali di Azure che è possibile distribuire come generazione 2. L'articolo elenca anche le differenze funzionali tra le macchine virtuali di prima e seconda generazione in Azure.

Quando si distribuisce una macchina virtuale, l'immagine del sistema operativo scelta determina se la macchina virtuale sarà una macchina virtuale di prima o di seconda generazione. Le versioni più recenti di tutte le immagini del sistema operativo per SAP disponibili in Azure (Red Hat Enterprise Linux, SuSE Enterprise Linux e Windows o Oracle Enterprise Linux) sono disponibili sia nella generazione 1 che nella seconda generazione. È importante selezionare attentamente un'immagine in base alla descrizione dell'immagine per distribuire la generazione corretta della macchina virtuale. Analogamente, è possibile creare immagini personalizzate del sistema operativo come generazione 1 o seconda generazione e influiscono sulla generazione della macchina virtuale quando la macchina virtuale è in distribuzione.

La modifica di una macchina virtuale distribuita dalla generazione 1 alla generazione 2 non è possibile in Azure. Per modificare la generazione di macchine virtuali, è necessario distribuire una nuova macchina virtuale che rappresenta la generazione desiderata e reinstallare il software nella nuova generazione di macchine virtuali. Questa modifica influisce solo sull'immagine VHD di base della macchina virtuale e non ha alcun impatto sui dischi dati o sulle condivisioni SMB (Network File System) o SMB (Server Message Block). I dischi dati, le condivisioni NFS o le condivisioni SMB assegnate in origine a una macchina virtuale di prima generazione possono essere allegate a una nuova macchina virtuale di seconda generazione.

Alcune famiglie di macchine virtuali, ad esempio la serie Mv2, supportano solo la seconda generazione. Lo stesso requisito potrebbe essere vero per le nuove famiglie di macchine virtuali in futuro. In questo scenario non è possibile ridimensionare una macchina virtuale di prima generazione esistente per lavorare con la nuova famiglia di macchine virtuali. Oltre ai requisiti di seconda generazione della piattaforma Azure, i componenti SAP potrebbero avere requisiti correlati alla generazione di una macchina virtuale. Per informazioni sui requisiti di seconda generazione per la famiglia di macchine virtuali scelta, vedere la nota SAP 1928533.

Limiti delle prestazioni per le macchine virtuali di Azure

Come cloud pubblico, Azure dipende dalla condivisione dell'infrastruttura in modo protetto in tutta la base dei clienti. Per abilitare il ridimensionamento e la capacità, vengono definiti limiti di prestazioni per ogni risorsa e servizio. Sul lato di calcolo dell'infrastruttura di Azure è importante considerare i limiti definiti per ogni dimensione della macchina virtuale.

Ogni macchina virtuale ha una quota diversa su disco e velocità effettiva di rete, il numero di dischi che possono essere allegati, se dispone di una risorsa di archiviazione temporanea locale con limiti di velocità effettiva e operazioni di I/O al secondo, dimensioni della memoria e numero di vCPU disponibili.

Analogamente alle macchine virtuali, esistono gli stessi limiti di prestazioni per ogni tipo di archiviazione per un carico di lavoro SAP e per tutti gli altri servizi di Azure.

Quando si pianifica e si sceglie macchine virtuali da usare nella distribuzione SAP, tenere presenti questi fattori:

• Iniziare con i requisiti di memoria e CPU. Separare i requisiti SAPS per la potenza della CPU nella parte DBMS e nelle parti dell'applicazione SAP. Per i sistemi esistenti, i valori SAPS correlati all'hardware spesso utilizzati possono essere determinati o stimati in base ai benchmark dell'applicazione standard SAP. Per i sistemi SAP appena distribuiti, completare un esercizio di ridimensionamento per determinare i requisiti SAPS per il sistema.

• Per i sistemi esistenti, è necessario misurare la velocità effettiva di I/O e le operazioni di I/O nel server DBMS. Per i sistemi appena, l'esercizio di ridimensionamento per il nuovo sistema deve fornire anche un'idea generale dei requisiti I/O sul lato DBMS. In caso di dubbi, è opportuno eseguire un modello di verifica.

• confrontare i requisiti SAPS per il server DBMS con i valori SAPS forniti dai diversi tipi di macchine virtuali di Azure. Le informazioni sui valori SAPS dei diversi tipi di VM di Azure sono documentate nella nota SAP 1928533. È opportuno concentrarsi prima di tutto sulla macchina virtuale DBMS perché, nella maggior parte delle distribuzioni, il livello di database è il livello di un sistema SAP NetWeaver che non esegue lo scale-out. Al contrario, il livello applicazione SAP può essere scalato orizzontalmente. Le singole guide DBMS descrivono le configurazioni di archiviazione consigliate.

• Riepilogare i risultati per:

  • Numero di macchine virtuali di Azure che si prevede di usare.
  • Singola famiglia di MACCHINE virtuali e SKU di MACCHINE virtuali per ogni livello SAP: DBMS, (A)SCS e server applicazioni.
  • La velocità effettiva di I/O misura o i requisiti di capacità di archiviazione calcolati.

Servizio istanze Large di HANA

Azure offre funzionalità di calcolo per eseguire uno scale-up o scale-out di un database HANA di grandi dimensioni su un'offerta dedicata denominata SAP HANA in istanze Large di Azure. Questa offerta estende le macchine virtuali disponibili in Azure.

Archiviazione per SAP in Azure

Le macchine virtuali di Azure usano varie opzioni di archiviazione per la persistenza. In termini semplici, le macchine virtuali possono essere suddivise in tipi di archiviazione permanenti e temporanei o non persistenti.

È possibile scegliere tra più opzioni di archiviazione per carichi di lavoro SAP e per componenti SAP specifici. Per altre informazioni, vedere Archiviazione di Azure per carichi di lavoro SAP. L'articolo illustra l'architettura di archiviazione per ogni parte di SAP: sistema operativo, file binari dell'applicazione, file di configurazione, dati di database, file di log e di traccia e interfacce di file con altre applicazioni, archiviate su disco o accessibili nelle condivisioni file.

Disco temporaneo nelle macchine virtuali

La maggior parte delle macchine virtuali di Azure per SAP offre un disco temporaneo che non è un disco gestito. Usare un disco temporaneo solo per i dati esplorabili. I dati in un disco temporaneo potrebbero essere persi durante eventi di manutenzione imprevisti o durante la ridistribuzione della macchina virtuale. Le caratteristiche delle prestazioni del disco temporaneo li rendono ideali per lo scambio o la pagina dei file del sistema operativo.

Nessun dato del sistema operativo non apribile o dell'applicazione deve essere archiviato in un disco temporaneo. Negli ambienti Windows, l'unità temporanea è in genere accessibile come unità D. Nei sistemi Linux il punto di montaggio è spesso /dev/sdb device, /mnt o /mnt/resource.

Alcune macchine virtuali non offrono un'unità temporanea. Se si prevede di usare queste dimensioni di VM per SAP, potrebbe essere necessario aumentare le dimensioni del disco del sistema operativo. Per altre informazioni, vedere la nota SAP n. 1928533. Per le macchine virtuali con un disco temporaneo, ottenere informazioni sulle dimensioni temporanee del disco e sui limiti di IOPS e velocità effettiva per ogni serie di macchine virtuali in Dimensioni per le macchine virtuali in Azure.

Non è possibile ridimensionare direttamente tra una serie di macchine virtuali con dischi temporanei e una serie di macchine virtuali che non dispone di dischi temporanei. Attualmente, un ridimensionamento tra due famiglie di macchine virtuali di questo tipo ha esito negativo. Una risoluzione consiste nel ricreare la macchina virtuale che non ha un disco temporaneo nelle nuove dimensioni usando uno snapshot del disco del sistema operativo. Mantenere tutti gli altri dischi dati e l'interfaccia di rete. Informazioni su come ridimensionare le dimensioni di una macchina virtuale con un disco temporaneo locale in una dimensione di macchina virtuale che non lo è.

Condivisioni di rete e volumi per SAP

I sistemi SAP richiedono in genere una o più condivisioni file di rete. Le condivisioni file sono in genere una delle opzioni seguenti:

• Directory di trasporto SAP (/usr/sap/trans o TRANSDIR).
• Volumi SAP o volumi sapmnt o saploc condivisi per distribuire più server applicazioni.
• Volumi di architettura a disponibilità elevata per SAP (A)SCS, SAP ERS o un database (/hana/shared).
• Interfacce di file che eseguono applicazioni di terze parti per l'importazione e l'esportazione di file.

In questi scenari è consigliabile usare un servizio di Azure, ad esempio File di Azure o Azure NetApp Files. Se questi servizi non sono disponibili nelle aree scelte o se non sono disponibili per l'architettura della soluzione, le alternative sono fornire condivisioni file NFS o SMB da applicazioni basate su VM autogestite o da servizi di terze parti. Vedere la nota SAP 2015553 sulle limitazioni al supporto SAP se si usano servizi di terze parti per i livelli di archiviazione in un sistema SAP in Azure.

A causa della natura spesso critica delle condivisioni di rete e poiché spesso sono un singolo punto di errore in una progettazione (per la disponibilità elevata) o un processo (per l'interfaccia file), è consigliabile basarsi su ogni servizio nativo di Azure per la propria disponibilità, contratto di servizio e resilienza. Nella fase di pianificazione è importante considerare questi fattori:

• Progettazione di condivisioni NFS o SMB, incluse le condivisioni da usare per ID sistema SAP (SID), per panorama e per area.
• Dimensionamento delle subnet, incluso il requisito IP per endpoint privati o subnet dedicate per servizi come Azure NetApp Files.
• Routing di rete ai sistemi SAP e alle applicazioni connesse.
• Uso di un endpoint pubblico o privato per File di Azure.

Per informazioni sui requisiti e su come usare una condivisione NFS o SMB in uno scenario a disponibilità elevata, vedere Disponibilità elevata.

Sicurezza per il panorama SAP

Per proteggere il carico di lavoro SAP in Azure, è necessario pianificare più aspetti della sicurezza:

• Segmentazione di rete e sicurezza di ogni subnet e interfaccia di rete.
• Crittografia in ogni livello all'interno dell'ambiente SAP.
• Soluzione di gestione delle identità per gli utenti finali e l'accesso amministrativo e i servizi Single Sign-On.
• Monitoraggio delle minacce e delle operazioni.

Gli argomenti di questo capitolo non sono un elenco completo di tutti i servizi, le opzioni e le alternative disponibili. Vengono elencate diverse procedure consigliate da considerare per tutte le distribuzioni SAP in Azure. Esistono altri aspetti da coprire a seconda dei requisiti aziendali o del carico di lavoro. Per altre informazioni sulla progettazione della sicurezza, vedere le risorse seguenti per indicazioni generali su Azure:

• Azure Well-Architected Framework: pilastro Sicurezza
• Azure Cloud Adoption Framework: Sicurezza

Proteggere le reti virtuali usando i gruppi di sicurezza

La pianificazione del panorama SAP in Azure deve includere un certo grado di segmentazione di rete, con reti virtuali e subnet dedicate solo ai carichi di lavoro SAP. Le procedure consigliate per la definizione della subnet sono descritte in Rete e in altre guide all'architettura di Azure. È consigliabile usare gruppi di sicurezza di rete con i gruppi di sicurezza delle applicazioni all'interno dei gruppi di sicurezza di rete per consentire la connettività in ingresso e in uscita. Quando si progettano gruppi di sicurezza di rete, ogni scheda di interfaccia di rete in una macchina virtuale può essere associata a più gruppi asg, in modo da poter creare gruppi diversi. Ad esempio, creare un gruppo di sicurezza di azure per le macchine virtuali DBMS, che contiene tutti i server di database nel panorama. Creare un altro asg per tutte le macchine virtuali (applicazione e DBMS) di un singolo SID SAP. In questo modo, è possibile definire una regola del gruppo di sicurezza di rete per il gruppo di sicurezza di rete del database complessivo e un'altra regola più specifica solo per il gruppo di sicurezza di rete specifico del SID.

I gruppi di sicurezza di rete non limitano le prestazioni con le regole definite per il gruppo di sicurezza di rete. Per il monitoraggio del flusso del traffico, è possibile attivare facoltativamente la registrazione dei flussi del gruppo di sicurezza di rete con i log valutati da un sistema di gestione degli eventi informativi (SIEM) o dal sistema di rilevamento delle intrusioni (IDS) di propria scelta per monitorare e agire su attività di rete sospette.

Endpoint privati per i servizi

Molti servizi PaaS di Azure sono accessibili per impostazione predefinita tramite un endpoint pubblico. Anche se l'endpoint di comunicazione si trova nella rete back-end di Azure, l'endpoint viene esposto alla rete Internet pubblica. Gli endpoint privati sono un'interfaccia di rete all'interno della propria rete virtuale privata. Tramite Collegamento privato di Azure, l'endpoint privato proietta il servizio nella rete virtuale. I servizi PaaS selezionati vengono quindi accessibili privatamente tramite l'indirizzo IP all'interno della rete. A seconda della configurazione, il servizio può essere potenzialmente impostato per comunicare solo tramite endpoint privato.

L'uso di un endpoint privato aumenta la protezione dalla perdita di dati e spesso semplifica l'accesso da reti locali e con peering. In molte situazioni, il routing di rete e il processo per aprire le porte del firewall, che spesso sono necessarie per gli endpoint pubblici, è semplificato. Le risorse si trovano già all'interno della rete perché sono accessibili da un endpoint privato.

Per informazioni sui servizi di Azure che offrono l'opzione per l'uso di un endpoint privato, vedere Servizi disponibili di Collegamento privato. Per NFS o SMB con File di Azure, è consigliabile usare sempre endpoint privati per i carichi di lavoro SAP. Per informazioni sugli addebiti sostenuti tramite il servizio, vedere Prezzi degli endpoint privati. Alcuni servizi di Azure potrebbero includere facoltativamente il costo con il servizio. Queste informazioni sono incluse nelle informazioni sui prezzi di un servizio.

Crittografia

A seconda dei criteri aziendali, la crittografia oltre le opzioni predefinite in Azure potrebbe essere necessaria per i carichi di lavoro SAP.

Crittografia per le risorse dell'infrastruttura

Per impostazione predefinita, i dischi gestiti e l'archiviazione BLOB in Azure vengono crittografati con una chiave gestita dalla piattaforma (PMK). Inoltre, la crittografia BYOK (Bring Your Own Key) per i dischi gestiti e l'archiviazione BLOB è supportata per i carichi di lavoro SAP in Azure. Per la crittografia del disco gestito, è possibile scegliere tra diverse opzioni, a seconda dei requisiti di sicurezza aziendali. Le opzioni di crittografia di Azure includono:

• PMK di crittografia lato archiviazione (SSE) (SSE-PMK)
• Chiave gestita dal cliente SSE (SSE-CMK)
• Doppia crittografia dei dati inattivi
• Crittografia basata su host

Per altre informazioni, inclusa una descrizione di Crittografia dischi di Azure, vedere un confronto tra le opzioni di crittografia di Azure.

Per le distribuzioni SAP nei sistemi Linux, non usare Crittografia dischi di Azure. Crittografia dischi di Azure comporta l'esecuzione della crittografia all'interno delle macchine virtuali SAP usando chiavi gestite dal cliente di Azure Key Vault. Per Linux, Crittografia dischi di Azure non supporta le immagini del sistema operativo usate per i carichi di lavoro SAP. Crittografia dischi di Azure può essere usata nei sistemi Windows con carichi di lavoro SAP, ma non combinare Crittografia dischi di Azure con la crittografia nativa del database. È consigliabile usare la crittografia nativa del database anziché Crittografia dischi di Azure. Per ulteriori informazioni, vedi la sezione successiva.

Analogamente alla crittografia dei dischi gestiti, la crittografia dei File di Azure inattivi (SMB e NFS) è disponibile con PMK o CMK.

Per le condivisioni di rete SMB, Prendere in esame attentamente i File di Azure e le dipendenze del sistema operativo con le versioni SMB perché la configurazione influisce sul supporto per la crittografia in transito.

Crittografia per i componenti SAP

La crittografia a livello SAP può essere separata in due livelli:

• Crittografia DBMS
• Crittografia del trasporto

Per la crittografia DBMS, ogni database supportato per una distribuzione SAP NetWeaver o SAP S/4HANA supporta la crittografia nativa. Transparent Database Encryption è completamente indipendente da qualsiasi crittografia dell'infrastruttura abilitata in Azure. È possibile usare SSE e la crittografia del database contemporaneamente. Quando si usa la crittografia, la posizione, l'archiviazione e la conservazione sicura delle chiavi di crittografia è fondamentale. Qualsiasi perdita di chiavi di crittografia comporta la perdita di dati perché non sarà possibile avviare o ripristinare il database.

Alcuni database potrebbero non avere un metodo di crittografia del database o potrebbero non richiedere un'impostazione dedicata per abilitare. Per altri database, i backup DBMS potrebbero essere crittografati in modo implicito quando viene attivata la crittografia del database. Vedere la documentazione SAP seguente per informazioni su come abilitare e usare Transparent Database Encryption:

• Dati SAP HANA e crittografia di volume di log
• SQL Server: nota SAP 1380493
• Oracle: nota SAP 974876
• IBM Db2: nota SAP 1555903
• SAP ASE: nota SAP 1972360

Contattare SAP o il fornitore DBMS per assistenza su come abilitare, usare o risolvere i problemi di crittografia software.

È possibile applicare la crittografia del trasporto o della comunicazione alle connessioni di SQL Server tra i motori SAP e il sistema DBMS. Analogamente, è possibile crittografare le connessioni dal livello di presentazione SAP (connessione di rete sicura SAPGui o SNC) o da una connessione HTTPS a un front-end Web. Vedere la documentazione del fornitore delle applicazioni per abilitare e gestire la crittografia in transito.

Monitoraggio e avviso sulle minacce

Per distribuire e usare soluzioni di monitoraggio delle minacce e avvisi, iniziare usando l'architettura dell'organizzazione. I servizi di Azure forniscono la protezione dalle minacce e una visualizzazione della sicurezza che è possibile incorporare nel piano di distribuzione SAP complessivo. Microsoft Defender per il cloud soddisfa i requisiti di protezione dalle minacce. Microsoft Defender per il cloud in genere fa parte di un modello di governance generale per un'intera distribuzione di Azure, non solo per i componenti SAP.

Per altre informazioni sulle soluzioni di gestione degli eventi su informazioni di sicurezza (SIEM) e di risposta automatica all'orchestrazione della sicurezza (SOAR), vedere Soluzioni di Microsoft Sentinel per l'integrazione SAP.

Software di sicurezza all'interno di macchine virtuali SAP

La nota SAP 2808515 per Linux e la nota SAP 106267 per Windows descrivono i requisiti e le procedure consigliate quando si usano scanner antivirus o software di sicurezza nei server SAP. È consigliabile seguire le raccomandazioni SAP quando si distribuiscono i componenti SAP in Azure.

Disponibilità elevata

La disponibilità elevata di SAP in Azure include due componenti:

• Disponibilità elevata dell'infrastruttura di Azure: disponibilità elevata dei servizi di calcolo di Azure, rete e archiviazione e come possono aumentare la disponibilità delle applicazioni SAP.

• Disponibilità elevata dell'applicazione SAP: come può essere combinato con la disponibilità elevata dell'infrastruttura di Azure usando la correzione del servizio. Esempio che usa la disponibilità elevata nei componenti software SAP:

  • Un'istanza SAP (A)SCS e SAP ERS
  • Server di database

Per altre informazioni sulla disponibilità elevata per SAP in Azure, vedere gli articoli seguenti:

• Scenari supportati: protezione a disponibilità elevata per il livello SAP DBMS
• Scenari supportati: disponibilità elevata per SAP Central Services
• Scenari supportati: archiviazione supportata per scenari di SAP Central Services
• Scenari supportati: cluster di failover di SAP Central Services multi-SID
• Disponibilità elevata in Macchine virtuali di Azure per SAP NetWeaver
• Architettura e scenari di disponibilità elevata per SAP NetWeaver
• Uso del riavvio delle macchine virtuali dell'infrastruttura di Azure per ottenere una maggiore disponibilità di un sistema SAP senza clustering
• Configurazioni del carico di lavoro SAP con le zone di disponibilità di Azure
• Connettività degli endpoint pubblici per le macchine virtuali usando Load Balancer Standard di Azure negli scenari a disponibilità elevata SAP

Pacemaker in Linux e il clustering di failover di Windows Server sono gli unici framework a disponibilità elevata per i carichi di lavoro SAP supportati direttamente da Microsoft in Azure. Qualsiasi altro framework a disponibilità elevata non è supportato da Microsoft e richiederà il supporto di progettazione, dettagli di implementazione e operazioni del fornitore. Per altre informazioni, vedere Scenari supportati per SAP in Azure.

Ripristino di emergenza

Spesso, le applicazioni SAP sono tra i processi più critici per l'azienda. In base alla loro importanza e al tempo necessario per essere di nuovo operativi dopo un'interruzione imprevista, gli scenari di continuità aziendale e ripristino di emergenza (BCDR) devono essere pianificati attentamente.

Per informazioni su come soddisfare questo requisito, vedere Panoramica del ripristino di emergenza e linee guida sull'infrastruttura per il carico di lavoro SAP.

Backup

Come parte della strategia BCDR, il backup per il carico di lavoro SAP deve essere parte integrante di qualsiasi distribuzione pianificata. La soluzione di backup deve coprire tutti i livelli di uno stack di soluzioni SAP: VM, sistema operativo, livello applicazione SAP, livello DBMS e qualsiasi soluzione di archiviazione condivisa. Anche il backup per i servizi di Azure usati dal carico di lavoro SAP e per altre risorse cruciali, ad esempio la crittografia e le chiavi di accesso, devono far parte della progettazione di backup e BCDR.

Backup di Azure offre soluzioni PaaS per il backup:

• Configurazione della macchina virtuale, sistema operativo e livello applicazione SAP (ridimensionamento dei dati su dischi gestiti) tramite Backup di Azure per la macchina virtuale. Prendere in esame la matrice di supporto per verificare che l'architettura possa usare questa soluzione.
• Backup di log e dati del database di SQL Server e SAP HANA. Include il supporto per le tecnologie di replica di database, ad esempio la replica di sistema HANA o SQL Always On, e il supporto tra aree per le aree abbinate.
• Backup della condivisione file tramite File di Azure. Verificare il supporto per NFS o SMB e altri dettagli di configurazione.

In alternativa, se si distribuisce Azure NetApp Files, le opzioni di backup sono disponibili a livello di volume, tra cui l'integrazione di SAP HANA e Oracle DBMS con un backup pianificato.

Le soluzioni di Backup di Azure offrono un'opzione di eliminazione temporanea per evitare eliminazioni dannose o accidentali e per evitare la perdita di dati. L'eliminazione temporanea è disponibile anche per le condivisioni file distribuite tramite File di Azure.

Le opzioni di backup sono disponibili per una soluzione creata e gestita dall'utente oppure se si usa software di terze parti. Un'opzione consiste nell'usare i servizi con Archiviazione di Azure, inclusa l'uso dell'archiviazione non modificabile per i dati BLOB. Questa opzione autogestito è attualmente necessaria come opzione di backup DBMS per alcuni database come SAP ASE o IBM Db2.

Usare le raccomandazioni nelle procedure consigliate di Azure per proteggere e convalidare gli attacchi ransomware.

Backup tra aree

Per qualsiasi requisito di backup tra aree, determinare l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO) offerti dalla soluzione e se corrisponde alla progettazione e alle esigenze BCDR.

Migrazione SAP ad Azure

Non è possibile descrivere tutti gli approcci e le opzioni di migrazione per l'ampia gamma di prodotti SAP, dipendenze delle versioni e tecnologie DBMS native e del sistema operativo nativo disponibili. Il team di progetto per l'organizzazione e i rappresentanti del lato del provider di servizi devono prendere in considerazione diverse tecniche per una migrazione SAP uniforme ad Azure.

• Testare le prestazioni durante la migrazione. Una parte importante della pianificazione della migrazione SAP è il test delle prestazioni tecniche. Il team di migrazione deve consentire tempo e disponibilità sufficienti per il personale chiave di eseguire applicazioni e test tecnici del sistema SAP migrato, incluse le interfacce connesse e le applicazioni. Per una migrazione SAP riuscita, è fondamentale confrontare la premigration e il runtime post-migrazione e l'accuratezza dei processi aziendali chiave in un ambiente di test. Usare le informazioni per ottimizzare i processi prima di eseguire la migrazione dell'ambiente di produzione.

• Usare i servizi di Azure per la migrazione SAP. Alcuni carichi di lavoro basati su macchine virtuali vengono migrati senza andare ad Azure usando servizi come Azure Migrate o Azure Site Recoveryo uno strumento di terze parti. Verificare con attenzione che la versione del sistema operativo e il carico di lavoro SAP eseguito siano supportate dal servizio.

  Spesso, qualsiasi carico di lavoro del database non è intenzionalmente supportato perché un servizio non può garantire la coerenza del database. Se il tipo DBMS è supportato dal servizio di migrazione, la frequenza di modifica o varianza del database è spesso troppo elevata. I sistemi SAP più occupati non soddisfano la frequenza di modifica consentita dagli strumenti di migrazione. I problemi potrebbero non essere visualizzati o individuati fino alla migrazione di produzione. In molte situazioni, alcuni servizi di Azure non sono adatti per la migrazione di sistemi SAP. Azure Site Recovery e Azure Migrate non hanno la convalida per una migrazione SAP su larga scala. Una metodologia di migrazione SAP collaudata consiste nell'affidarsi alla replica DBMS o agli strumenti di migrazione SAP.

  Una distribuzione in Azure anziché una migrazione di macchine virtuali di base è preferibile e più semplice da eseguire rispetto a una migrazione locale. I framework di distribuzione automatizzati, ad esempio Centro di Azure per soluzioni SAP e il framework di automazione della distribuzione di Azure, consentono un'esecuzione rapida delle attività automatizzate. Per eseguire la migrazione del panorama SAP a una nuova infrastruttura distribuita usando tecnologie di replica nativa DBMS come la replica di sistema HANA, il backup e il ripristino dbMS o gli strumenti di migrazione SAP usano conoscenze tecniche consolidate del sistema SAP.

• Aumento delle prestazioni dell'infrastruttura. Durante una migrazione SAP, una maggiore capacità dell'infrastruttura consente di distribuire più rapidamente. Il team di progetto deve prendere in considerazione l'aumento delle dimensioni della macchina virtuale per fornire una quantità maggiore di CPU e memoria. Il team deve anche prendere in considerazione la possibilità di aumentare la velocità effettiva di archiviazione e archiviazione aggregata delle macchine virtuali. Analogamente, a livello di macchina virtuale, prendere in considerazione elementi di archiviazione come singoli dischi per aumentare la velocità effettiva con bursting on-demand e livelli di prestazioni per SSD Premium v1. Aumentare i valori di operazioni di I/O al secondo e velocità effettiva se si usa SSD Premium v2 sopra i valori configurati. Ingrandire le condivisioni file NFS e SMB per aumentare i limiti di prestazioni. Tenere presente che Non è possibile ridurre le dimensioni dei dischi gestiti da Azure e che la riduzione delle dimensioni, dei livelli di prestazioni e degli indicatori KPI di velocità effettiva può avere diversi tempi di raffreddamento.

• Ottimizzare la copia di dati e di rete. La migrazione di un sistema SAP ad Azure comporta sempre lo spostamento di una grande quantità di dati. I dati possono essere backup di database e file o replica, un trasferimento dei dati da applicazione a applicazione o un'esportazione della migrazione SAP. A seconda del processo di migrazione usato, è necessario scegliere il percorso di rete corretto per spostare i dati. Per molte operazioni di spostamento dei dati, l'uso di Internet invece di una rete privata è il percorso più rapido per copiare i dati in modo sicuro nell'archiviazione di Azure.

  L'uso di ExpressRoute o una VPN può causare colli di bottiglia:

  • I dati di migrazione usano una larghezza di banda eccessiva e interferiscono con l'accesso degli utenti ai carichi di lavoro in esecuzione in Azure.
  • I colli di bottiglia di rete in locale, ad esempio un firewall o una limitazione della velocità effettiva, vengono spesso individuati solo durante la migrazione.

  Indipendentemente dalla connessione di rete usata, le prestazioni di rete a flusso singolo per uno spostamento dei dati sono spesso ridotte. Per aumentare la velocità di trasferimento dei dati su più flussi TCP, usare strumenti che possono supportare più flussi. Applicare tecniche di ottimizzazione descritte nella documentazione SAP e in molti post di blog su questo argomento.

Supporto e operazioni per SAP

Alcune altre aree sono importanti da considerare prima e durante la distribuzione SAP in Azure.

Estensione della macchina virtuale Azure per SAP

L'Estensione monitoraggio di Azure, Monitoraggio avanzato e l'Estensione di Azure per SAP fanno tutti riferimento a un'estensione di macchina virtuale che è necessario distribuire per fornire alcuni dati di base sull'infrastruttura di Azure all'agente host SAP. L note SAP possono fare riferimento all'estensione come Estensione di monitoraggio o Monitoraggio avanzato. In Azure si chiama Estensione di Azure per SAP. Ai fini del supporto, l'estensione deve essere installata in tutte le macchine virtuali di Azure che eseguono un carico di lavoro SAP. Per altre informazioni, vedere Estensione di macchina virtuale di Azure per SAP.

SAProuter per il supporto SAP

L'uso di un panorama SAP in Azure richiede la connettività da e verso SAP a scopo di supporto. In genere, la connettività è sotto forma di connessione SAProuter, se è tramite un canale di rete di crittografia su Internet o tramite una connessione VPN privata a SAP. Per le procedure consigliate e per un'implementazione di esempio di SAProuter in Azure, vedere lo scenario di architettura in Connessioni Internet in ingresso e in uscita per SAP in Azure.

Passaggi successivi

• Distribuire un carico di lavoro SAP in Azure
• Considerazioni sulla distribuzione DBMS di macchine virtuali di Azure per un carico di lavoro SAP
• Carichi di lavoro SAP in Azure: elenco di controllo per la pianificazione e la distribuzione
• Set di scalabilità di macchine virtuali per il carico di lavoro SAP