Eseguire SAP NetWeaver in Windows in Azure

Questa guida presenta un set di procedure comprovate per l'esecuzione di SAP NetWeaver in un ambiente Windows, in Azure, con disponibilità elevata. Il database è AnyDB, il termine SAP per qualsiasi sistema di gestione di database supportato (DBMS) oltre a SAP HANA.

Architettura

Il diagramma seguente illustra SAP NetWeaver in un ambiente Windows.

Scaricare un file di Visio di questa architettura.

Questa guida descrive un sistema di produzione. Il sistema viene distribuito con dimensioni di macchina virtuale specifiche che è possibile modificare per soddisfare le esigenze dell'organizzazione. Il sistema può essere ridotto a una singola macchina virtuale. In questa guida il layout di rete è notevolmente semplificato per illustrare i principi architetturali. Non è progettato per descrivere una rete aziendale completa.

Workflow

Reti virtuali. Il servizio Azure Rete virtuale connette le risorse di Azure tra loro con sicurezza avanzata. In questa architettura la rete virtuale si connette a una rete locale tramite un gateway Azure ExpressRoute distribuito nell'hub di una topologia hub-spoke. Lo spoke è la rete virtuale usata per le applicazioni SAP e i livelli di database. La rete virtuale hub viene usata per i servizi condivisi, ad esempio Azure Bastion e il backup.

Peering di reti virtuali. Questa architettura usa una topologia di rete hub-spoke con più reti virtuali con peering. Questa topologia fornisce la segmentazione di rete e l'isolamento per i servizi distribuiti in Azure. Il peering consente la connettività trasparente tra reti virtuali con peering tramite la rete backbone Microsoft. Non comporta una riduzione delle prestazioni se distribuita all'interno di una singola area. La rete virtuale è suddivisa in subnet separate per ogni livello: applicazione (SAP NetWeaver), database e servizi condivisi come Bastion e una soluzione di backup di terze parti.

VM. Questa architettura usa le macchine virtuali per il livello applicazione e il livello di database, raggruppati nel modo seguente:

• SAP NetWeaver. Il livello applicazione usa macchine virtuali Windows per eseguire SAP Central Services e server applicazioni SAP. Per la disponibilità elevata, le macchine virtuali che eseguono Central Services vengono configurate in un cluster di failover di Windows Server. Sono supportati da condivisioni file di Azure o dischi condivisi di Azure.

• AnyDB. Il livello di database esegue AnyDB come database, che può essere Microsoft SQL Server, Oracle o IBM Db2.

• Servizio Bastion. Gli amministratori usano una macchina virtuale con sicurezza migliorata denominata bastion host per connettersi ad altre macchine virtuali. In genere fa parte dei servizi condivisi, ad esempio i servizi di backup. Se Secure Shell Protocol (SSH) e Remote Desktop Protocol (RDP) sono gli unici servizi usati per l'amministrazione del server, un host Azure Bastion è una buona soluzione. Se si usano altri strumenti di gestione, ad esempio SQL Server Management Studio o SAP Frontend, usare una jump box tradizionale auto-distribuita.

DNS privato servizio. Azure DNS privato fornisce un servizio DNS affidabile e sicuro per la rete virtuale. Azure DNS privato gestisce e risolve i nomi di dominio nella rete virtuale, senza la necessità di configurare una soluzione DNS personalizzata.

Servizi di bilanciamento del carico. Per distribuire il traffico alle macchine virtuali nella subnet del livello applicazione SAP per la disponibilità elevata, è consigliabile usare un servizio di bilanciamento del carico Standard di Azure. Si noti che un servizio di bilanciamento del carico standard offre un livello di sicurezza per impostazione predefinita. Le macchine virtuali che si trovano dietro un servizio di bilanciamento del carico standard non hanno connettività Internet in uscita. Per abilitare Internet in uscita nelle macchine virtuali, è necessario aggiornare la configurazione del servizio di bilanciamento del carico standard. Per la disponibilità elevata delle applicazioni basate sul Web SAP, usare sap Web Dispatcher predefinito o un altro servizio di bilanciamento del carico disponibile in commercio. Basare la selezione su:

• Tipo di traffico, ad esempio HTTP o GUI SAP.
• I servizi di rete necessari, ad esempio la terminazione SSL (Secure Sockets Layer).

Per alcuni esempi di progettazione in ingresso/in uscita con connessione Internet, vedere Connessioni Internet in ingresso e in uscita per SAP in Azure.

Load Balancer Standard supporta più indirizzi IP virtuali front-end. Questo supporto è ideale per le implementazioni del cluster che coinvolgono questi componenti:

• Advanced Business Application Programming (ABAP) SAP Central Service (ASCS)
• Enqueue Replication Server (ERS)

Lo SKU Standard supporta anche cluster SAP multi-SID (multi-SID). In altre parole, più sistemi SAP in Windows possono condividere un'infrastruttura a disponibilità elevata comune per risparmiare sui costi. Valutare i risparmi sui costi ed evitare di inserire troppi sistemi in un cluster. supporto tecnico di Azure non più di cinque SID per cluster.

Gateway applicazione. app Azure lication Gateway è un servizio di bilanciamento del carico del traffico Web che è possibile usare per gestire il traffico verso le applicazioni Web. I servizi di bilanciamento del carico tradizionali operano a livello di trasporto (OSI livello 4 - TCP e UDP). Instradano il traffico in base all'indirizzo IP di origine e alla porta a un indirizzo IP e a una porta di destinazione. gateway applicazione può prendere decisioni di routing basate su attributi aggiuntivi di una richiesta HTTP, ad esempio il percorso URI o le intestazioni host. Questo tipo di routing è detto bilanciamento del carico a livello di applicazione (OSI livello 7).

Gruppi di sicurezza di rete. Per limitare il traffico in ingresso, in uscita e all'interno della subnet in una rete virtuale, creare gruppi di sicurezza di rete.

Gruppi di sicurezza delle applicazioni. Per definire criteri di sicurezza di rete con granularità fine basati sul carico di lavoro incentrati sulle applicazioni, usare gruppi di sicurezza delle applicazioni anziché indirizzi IP espliciti. I gruppi di sicurezza delle applicazioni consentono di raggruppare le macchine virtuali in base al nome e di proteggere le applicazioni filtrando il traffico da segmenti attendibili della rete.

Gateway. Un gateway connette reti distinte, estendendo la rete locale alla rete virtuale di Azure. È consigliabile usare ExpressRoute per creare connessioni private che non passano tramite Internet pubblico, ma è anche possibile usare una connessione da sito a sito . Per ridurre la latenza o aumentare la velocità effettiva, prendere in considerazione Copertura globale di ExpressRoute ed ExpressRoute FastPath, come descritto più avanti in questo articolo.

Archiviazione di Azure. L'archiviazione fornisce la persistenza dei dati per una macchina virtuale sotto forma di disco rigido virtuale. È consigliabile usare Dischi gestiti di Azure.

Consigli

Questa architettura descrive una distribuzione di piccole dimensioni a livello di produzione. Le distribuzioni differiscono in base ai requisiti aziendali, quindi considerare questi consigli come punto di partenza.

Macchine virtuali

Nei pool e nei cluster del server applicazioni modificare il numero di macchine virtuali in base alle esigenze. Per informazioni dettagliate sull'esecuzione di SAP NetWeaver nelle macchine virtuali, vedere Pianificazione e implementazione di Azure Macchine virtuali per SAP NetWeaver.

Per informazioni dettagliate sul supporto SAP per i tipi di macchine virtuali di Azure e le metriche di velocità effettiva (SAPS), vedere la nota SAP 1928533. Per accedere alle note SAP, è necessario un account SAP Service Marketplace.

Dispatcher Web SAP

Il componente Web Dispatcher viene usato per il bilanciamento del carico del traffico SAP tra i server applicazioni SAP. Per ottenere la disponibilità elevata per il componente Web Dispatcher, Load Balancer viene usato per implementare il cluster di failover di istanze di Web Dispatcher o la configurazione parallela di Web Dispatcher. Per una descrizione dettagliata della soluzione, vedere Disponibilità elevata di SAP Web Dispatcher.

Pool di server applicazioni

La transazione SAP SMLG viene comunemente usata per gestire i gruppi di accesso per i server applicazioni ABAP e per bilanciare il carico degli utenti di accesso. Altre transazioni, ad esempio SM61 per i gruppi di server batch e RZ12 per i gruppi RFC (Remote Function Call), bilanciano anche il carico degli utenti di accesso. Queste transazioni usano la funzionalità di bilanciamento del carico all'interno del server messaggi di SAP Central Services per distribuire sessioni o carichi di lavoro in ingresso tra il pool di server applicazioni SAP per il traffico SAP GUIs e RFC.

Cluster SAP Central Services

Questa architettura esegue Central Services nelle macchine virtuali nel livello applicazione. Central Services è un potenziale punto di errore (SPOF) quando viene distribuito in una singola macchina virtuale. Per implementare una soluzione a disponibilità elevata, usare un cluster di condivisione file o un cluster su disco condiviso.

Per le condivisioni file a disponibilità elevata, sono disponibili diverse opzioni. È consigliabile usare File di Azure condivisioni come condivisioni SMB (Server Message Block) native del cloud o NFS (Network File System). Un'alternativa a File di Azure è Azure NetApp Files, che offre condivisioni NFS e SMB ad alte prestazioni.

È anche possibile implementare le condivisioni file a disponibilità elevata nelle istanze di Central Services usando un cluster di failover di Windows Server con File di Azure. Questa soluzione supporta anche un cluster Windows con dischi condivisi usando un disco condiviso di Azure come volume condiviso del cluster. Se si preferisce usare dischi condivisi, è consigliabile usare dischi condivisi di Azure per configurare un cluster di failover di Windows Server per il cluster SAP Central Services.

Esistono anche prodotti partner come SIOS DataKeeper Cluster Edition di SIOS Technology Corp. Questo componente aggiuntivo replica il contenuto da dischi indipendenti collegati ai nodi del cluster ASCS e quindi presenta i dischi come volume condiviso del cluster al software del cluster.

Se si usa il partizionamento di rete del cluster, il software del cluster usa i voti quorum per selezionare un segmento della rete e i relativi servizi associati da usare come cervello del cluster frammentato. Windows offre molti modelli quorum. Questa soluzione usa Cloud Witness perché è più semplice e offre maggiore disponibilità rispetto a un server di controllo del nodo di calcolo. Il server di controllo della condivisione file di Azure è un'altra alternativa per fornire un voto quorum del cluster.

In una distribuzione di Azure, i server applicazioni si connettono ai Servizi centrali a disponibilità elevata usando i nomi host virtuali dei servizi ASCS o ERS. Questi nomi host vengono assegnati alla configurazione IP front-end del cluster del servizio di bilanciamento del carico. Load Balancer supporta più indirizzi IP front-end, pertanto sia gli INDIRIZZI IP virtuali ASCS che gli INDIRIZZI VIP virtuali (ERS) possono essere associati a un servizio di bilanciamento del carico.

Rete

Questa architettura usa una topologia hub-spoke. La rete virtuale hub funge da punto centrale di connettività per una rete locale. Gli spoke sono reti virtuali che eseguono il peering con l'hub e isolano i carichi di lavoro SAP. Il traffico scorre tra il data center locale e l'hub attraverso una connessione gateway.

Schede di interfaccia di rete

Le schede di interfaccia di rete consentono tutte le comunicazioni tra macchine virtuali in una rete virtuale. Le tradizionali distribuzioni SAP locali implementano più schede di interfaccia di rete per ogni macchina per segregare il traffico amministrativo rispetto al traffico aziendale.

In Azure la rete virtuale è una rete software-defined che invia tutto il traffico attraverso la stessa infrastruttura di rete. Non è quindi necessario usare più schede di interfaccia di rete per motivi di prestazioni. Tuttavia, se l'organizzazione deve separare il traffico, è possibile distribuire più schede di interfaccia di rete per macchina virtuale e connettere ogni scheda di interfaccia di rete a una subnet diversa. È quindi possibile usare i gruppi di sicurezza di rete per applicare criteri di controllo di accesso diversi.

Le schede di interfaccia di rete di Azure supportano più indirizzi IP. Questo supporto è conforme alla procedura consigliata da SAP per l'uso dei nomi host virtuali per le installazioni. Per una struttura completa, vedere la nota SAP 962955. Per accedere alle note SAP, è necessario un account SAP Service Marketplace.

Subnet e gruppi di sicurezza di rete

Questa architettura suddivide lo spazio degli indirizzi delle rete virtuale in subnet. È possibile associare ogni subnet a un gruppo di sicurezza di rete che definisce i criteri di accesso per la subnet. Posizionare i server applicazioni in una subnet separata. In questo modo, è possibile proteggerli più facilmente gestendo i criteri di sicurezza della subnet anziché i singoli server.

Quando si associa un gruppo di sicurezza di rete a una subnet, il gruppo di sicurezza di rete si applica a tutti i server all'interno della subnet e offre un controllo granulare sui server. Configurare i gruppi di sicurezza di rete usando il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure.

Copertura globale di ExpressRoute

Se l'ambiente di rete include due o più connessioni ExpressRoute, Copertura globale di ExpressRoute consente di ridurre gli hop di rete e la latenza. Questa tecnologia è un peering di route BGP (Border Gateway Protocol) configurato tra due o più connessioni ExpressRoute per collegare due domini di routing ExpressRoute. Copertura globale riduce la latenza quando il traffico di rete attraversa più di una connessione ExpressRoute. Attualmente è disponibile solo per il peering privato nei circuiti ExpressRoute.

Al momento, non sono presenti elenchi di controllo di accesso di rete o altri attributi che possono essere modificati in Copertura globale. Di conseguenza, tutte le route apprese da un determinato circuito ExpressRoute (da locale e Azure) vengono annunciate attraverso il peering del circuito all'altro circuito ExpressRoute. È consigliabile stabilire un filtro del traffico di rete locale per limitare l'accesso alle risorse.

ExpressRoute FastPath

FastPath è progettato per migliorare le prestazioni del percorso dati tra la rete locale e la rete virtuale. Quando è abilitata, FastPath invia il traffico di rete direttamente alle macchine virtuali nella rete virtuale, ignorando il gateway.

Per tutte le nuove connessioni ExpressRoute ad Azure, FastPath è la configurazione predefinita. Per i circuiti ExpressRoute esistenti, contattare supporto tecnico di Azure per attivare FastPath.

FastPath non supporta il peering di rete virtuale. Se viene eseguito il peering di altre reti virtuali con una connessa a ExpressRoute, il traffico di rete dalla rete locale alle altre reti virtuali spoke viene inviato al gateway di rete virtuale. La soluzione alternativa consiste nel connettere direttamente tutte le reti virtuali al circuito ExpressRoute. Questa funzionalità è attualmente in anteprima pubblica.

Servizi di bilanciamento del carico

SAP Web Dispatcher gestisce il bilanciamento del carico del traffico HTTP(S) in un pool di server applicazioni SAP. Questo servizio di bilanciamento del carico software fornisce servizi a livello di applicazione (definiti livello 7 nel modello di rete ISO) che possono eseguire la terminazione SSL e altre funzioni di offload.

Azure Load Balancer è un servizio di livello di trasmissione di rete (livello 4) che bilancia il traffico usando un hash a cinque tuple dai flussi di dati. L'hash si basa su IP di origine, porta di origine, IP di destinazione, porta di destinazione e tipo di protocollo. Nelle distribuzioni SAP in Azure, Load Balancer viene usato nelle configurazioni del cluster per indirizzare il traffico all'istanza del servizio primario o al nodo integro in caso di errore.

È consigliabile usare Load Balancer Standard per tutti gli scenari SAP. Se le macchine virtuali nel pool back-end richiedono connettività in uscita pubblica o se vengono usate in una distribuzione di zona di Azure, Load Balancer Standard richiede configurazioni aggiuntive perché sono sicure per impostazione predefinita. Non consentono la connettività in uscita a meno che non venga configurata in modo esplicito.

Per il traffico dai client GUI SAP che si connettono a un server SAP tramite il protocollo DIAG o RFC, il server messaggi di Central Services bilancia il carico tramite i gruppi di accesso del server applicazioni SAP. Per questo tipo di installazione, non è necessario un altro servizio di bilanciamento del carico.

Storage

Alcune organizzazioni usano l'archiviazione standard per i server applicazioni. I dischi gestiti standard non sono supportati. Vedere la nota SAP 1928533. Per accedere alle note SAP, è necessario un account SAP Service Marketplace. È consigliabile usare dischi gestiti di Azure Premium in tutti i casi. Un aggiornamento recente alla nota SAP 2015553 esclude l'uso dell'archiviazione HDD Standard e dell'archiviazione SSD Standard per alcuni casi d'uso specifici.

I server applicazioni non ospitano dati aziendali. È quindi possibile usare anche i dischi P4 e P6 Premium più piccoli per ridurre al minimo i costi. In questo modo, è possibile trarre vantaggio dal contratto di servizio della macchina virtuale a istanza singola se si dispone di un'installazione centrale dello stack SAP.

Per gli scenari a disponibilità elevata, è possibile usare condivisioni file di Azure e dischi condivisi di Azure. I dischi gestiti ssd Premium di Azure e Archiviazione su disco Ultra di Azure sono disponibili per i dischi condivisi di Azure e l'unità SSD Premium è disponibile per le condivisioni file di Azure.

L'archiviazione viene usata anche da Cloud Witness per mantenere il quorum con un dispositivo in un'area di Azure remota, lontano dall'area primaria in cui risiede il cluster.

Per l'archivio dati di backup, è consigliabile usare i livelli di accesso ad accesso sporadico e archivio di Azure. Questi livelli di archiviazione offrono un modo conveniente per archiviare dati di lunga durata a cui si accede raramente.

L'archiviazione su disco SSD Premium v2 di Azure è progettata per carichi di lavoro critici per le prestazioni, ad esempio sistemi di elaborazione delle transazioni online che richiedono costantemente una latenza inferiore al millisecondo combinata con operazioni di I/O al secondo e velocità effettiva elevate.

L'archiviazione su disco Ultra riduce notevolmente la latenza del disco. Di conseguenza, offre vantaggi alle applicazioni critiche per le prestazioni, ad esempio i server di database SAP. Per confrontare le opzioni di archiviazione a blocchi in Azure, vedere Tipi di dischi gestiti di Azure.

Per un archivio dati condiviso a disponibilità elevata e ad alte prestazioni, usare Azure NetApp Files. Questa tecnologia è particolarmente utile per il livello di database quando si usa Oracle e anche quando si ospitano i dati dell'applicazione.

Considerazioni sulle prestazioni

I server applicazioni SAP comunicano costantemente con i server di database. Per le applicazioni critiche per le prestazioni eseguite su piattaforme di database, abilitare l'acceleratore di scrittura per il volume di log se si usa SSD Premium v1. In questo modo è possibile migliorare la latenza di scrittura dei log. L'acceleratore di scrittura è disponibile per le macchine virtuali serie M.

Per ottimizzare le comunicazioni tra server, usare Rete accelerata. La maggior parte delle dimensioni dell'istanza di macchina virtuale per utilizzo generico e ottimizzata per il calcolo con due o più vCPU supporta la rete accelerata. Nelle istanze che supportano l'hyperthreading, le istanze di macchine virtuali con quattro o più vCPU supportano la rete accelerata.

Per ottenere un numero elevato di operazioni di I/O al secondo e velocità effettiva del disco, seguire le procedure comuni nell'ottimizzazione delle prestazioni del volume di archiviazione, che si applicano al layout di archiviazione di Azure. Ad esempio, è possibile posizionare più dischi insieme per creare un volume disco con striping per migliorare le prestazioni di I/O. L'abilitazione della cache di lettura sul contenuto di archiviazione che viene modificato raramente migliora la velocità di recupero di dati.

Ssd Premium v2 offre prestazioni superiori rispetto alle unità SSD Premium ed è in genere meno costoso. È possibile impostare un disco SSD Premium v2 a qualsiasi dimensione supportata e regolare le prestazioni in modo granulare senza incorrere in tempi di inattività.

L'archiviazione su disco Ultra è disponibile per le applicazioni a elevato utilizzo di I/O. Dove sono disponibili questi dischi, è consigliabile usare l'archiviazione Premium dell'acceleratore di scrittura. È possibile aumentare o ridurre singolarmente le metriche delle prestazioni, ad esempio IOPS e MBps, senza dover riavviare.

Per indicazioni sull'ottimizzazione dell'archiviazione di Azure per i carichi di lavoro SAP in SQL Server, vedere Pianificazione e implementazione di Azure Macchine virtuali per SAP NetWeaver.

Il posizionamento di un'appliance virtuale di rete tra l'applicazione e i livelli di database per qualsiasi stack di applicazioni SAP non è supportato. Questa procedura introduce tempi di elaborazione significativi per i pacchetti di dati, che comporta prestazioni inaccettabili dell'applicazione.

Gruppi di posizionamento di prossimità

Alcune applicazioni SAP richiedono una comunicazione frequente con il database. La prossimità fisica dell'applicazione e dei livelli di database influisce sulla latenza di rete, che può influire negativamente sulle prestazioni dell'applicazione.

Per ottimizzare la latenza di rete, è possibile usare i gruppi di posizionamento di prossimità, che impostano un vincolo logico nelle macchine virtuali distribuite nei set di disponibilità. I gruppi di posizionamento di prossimità favoriscono la co-posizione e le prestazioni rispetto alla scalabilità, alla disponibilità o ai costi. Possono migliorare notevolmente l'esperienza utente per la maggior parte delle applicazioni SAP. Per gli script disponibili in GitHub dal team di distribuzione SAP, vedere Script.

Zone di disponibilità

Le zone di disponibilità consentono di distribuire macchine virtuali tra data center, che sono posizioni fisicamente separate all'interno di un'area di Azure specifica. Il loro scopo è quello di migliorare la disponibilità del servizio. Tuttavia, la distribuzione di risorse tra zone può aumentare la latenza, quindi tenere presenti considerazioni sulle prestazioni.

Gli amministratori necessitano di un profilo di latenza di rete chiaro tra tutte le zone di un'area di destinazione prima di poter determinare il posizionamento delle risorse con latenza minima tra zone. Per creare questo profilo, distribuire macchine virtuali di piccole dimensioni in ogni zona per il test. Gli strumenti consigliati per questi test includono PsPing e Iperf. Al termine dei test, rimuovere le macchine virtuali usate per il test. In alternativa, è consigliabile usare uno strumento di controllo della latenza tra zone di Azure.

Considerazioni sulla scalabilità

Per il livello dell'applicazione SAP, Azure offre un'ampia gamma di dimensioni delle macchine virtuali per l'aumento e la scalabilità orizzontale. Per un elenco inclusivo, vedere la nota SAP 1928533 - Applicazioni SAP in Azure: prodotti supportati e tipi di macchine virtuali di Azure. Per accedere alle note SAP, è necessario un account SAP Service Marketplace.

È possibile ridimensionare i server applicazioni SAP e i cluster Central Services verso l'alto e il basso. È anche possibile aumentare o ridurre le istanze modificando il numero di istanze usate. Il database AnyDB può aumentare e ridurre le prestazioni, ma non aumenta il numero di istanze. Il contenitore di database SAP per AnyDB non supporta il partizionamento orizzontale.

Considerazioni sulla disponibilità

La ridondanza delle risorse è il tema generale nelle soluzioni di infrastruttura a disponibilità elevata. Per i contratti di servizio di disponibilità delle macchine virtuali a istanza singola per vari tipi di archiviazione, vedere Contratto di servizio per le macchine virtuali. Per aumentare la disponibilità del servizio in Azure, distribuire le risorse delle macchine virtuali con set di scalabilità di macchine virtuali con orchestrazione flessibile, zone di disponibilità o set di disponibilità.

Con Azure, la distribuzione del carico di lavoro SAP può essere a livello di area o di zona, a seconda dei requisiti di disponibilità e resilienza delle applicazioni SAP. Azure offre diverse opzioni di distribuzione, ad esempio set di scalabilità di macchine virtuali con orchestrazione flessibile (FD=1), zone di disponibilità e set di disponibilità, per migliorare la disponibilità delle risorse. Per comprendere in modo completo le opzioni di distribuzione disponibili e la relativa applicabilità in aree di Azure diverse (incluse le zone, all'interno di una singola zona o in un'area senza zone), vedere Architettura e scenari a disponibilità elevata per SAP NetWeaver.

In questa installazione distribuita dell'applicazione SAP l'installazione di base viene replicata per ottenere la disponibilità elevata. Per ogni livello dell'architettura, la progettazione a disponibilità elevata varia.

Dispatcher Web nel livello server applicazioni

Il componente Web Dispatcher viene usato come servizio di bilanciamento del carico per il traffico SAP tra i server applicazioni SAP. Per ottenere la disponibilità elevata di SAP Web Dispatcher, Load Balancer implementa il cluster di failover o la configurazione parallela di Web Dispatcher.

Per le comunicazioni con connessione Internet, è consigliabile una soluzione autonoma nella rete perimetrale, nota anche come rete perimetrale, per soddisfare i problemi di sicurezza.

Il dispatcher Web incorporato in ASCS è un'opzione speciale. Se si usa questa opzione, prendere in considerazione il dimensionamento corretto a causa del carico di lavoro aggiuntivo in ASCS.

Central Services nel livello server applicazioni

La disponibilità elevata di Central Services viene implementata con un cluster di failover di Windows Server. Quando l'archiviazione cluster per il cluster di failover viene distribuita in Azure, è possibile configurarla in due modi: come disco condiviso cluster o come condivisione file in cluster.

• È consigliabile usare File di Azure come condivisioni SMB o NFS completamente gestite e native del cloud. Un altro modo consiste nell'usare Azure NetApp Files, che offre condivisioni NFS e SMB di classe enterprise ad alte prestazioni.

• Esistono due modi per configurare i cluster con dischi condivisi in Azure. Prima di tutto, è consigliabile usare dischi condivisi di Azure per configurare un cluster di failover di Windows Server per SAP Central Services. Per un esempio di implementazione, vedere Cluster ASCS con dischi condivisi di Azure. Un altro modo per implementare un disco condiviso in cluster consiste nell'usare SIOS DataKeeper per eseguire le attività seguenti:

  • Replicare il contenuto di dischi indipendenti collegati ai nodi del cluster.
  • Astrarre le unità come volume condiviso del cluster per gestione cluster.

  Per informazioni dettagliate sull'implementazione, vedere Clustering DI SAP ASCS in Azure con SIOS.

Se si usa Load Balancer Standard, è possibile abilitare la porta a disponibilità elevata. In questo modo, è possibile evitare di dover configurare regole di bilanciamento del carico per più porte SAP. Inoltre, quando si configurano i servizi di bilanciamento del carico di Azure, abilitare Direct Server Return (DSR), detto anche INDIRIZZO IP mobile. In questo modo è possibile consentire alle risposte del server di ignorare il servizio di bilanciamento del carico. Questa connessione diretta impedisce al servizio di bilanciamento del carico di diventare un collo di bottiglia nel percorso della trasmissione dei dati. È consigliabile abilitare DSR per i cluster di database e ASCS.

Servizi applicazioni nel livello server applicazioni

La disponibilità elevata per i server applicazioni SAP viene ottenuta bilanciando il carico del traffico all'interno di un pool di server applicazioni. Non sono necessari software cluster, SAP Web Dispatcher o il servizio di bilanciamento del carico di Azure. Il server messaggi SAP può bilanciare il carico del traffico client verso i server applicazioni definiti in un gruppo di accesso ABAP dalla transazione SMLG.

Livello database

In questa architettura il database di origine viene eseguito in AnyDB, ovvero un DBMS come SQL Server, SAP ASE, IBM Db2 o Oracle. La funzionalità di replica nativa del livello di database fornisce failover manuale o automatico tra i nodi replicati.

Per informazioni di implementazione dettagliate per sistemi di database specifici, vedere Distribuzione DBMS di Macchine virtuali di Azure per SAP NetWeaver.

Macchine virtuali distribuite tra zone di disponibilità

Una zona di disponibilità è costituita da uno o più data center. È progettato per migliorare la disponibilità del carico di lavoro e proteggere i servizi e le macchine virtuali delle applicazioni dalle interruzioni del data center. Le macchine virtuali in una singola zona vengono considerate come se fossero in un singolo dominio di errore. Quando si seleziona la distribuzione a livello di zona, le macchine virtuali nella stessa zona vengono distribuite ai domini di errore in modo ottimale.

Nelle aree di Azure che supportano più zone sono disponibili almeno tre zone. Tuttavia, la distanza massima tra i data center in queste zone non è garantita. Per distribuire un sistema SAP multilibero tra zone, è necessario conoscere la latenza di rete all'interno di una zona e tra zone di destinazione. È anche necessario conoscere la sensibilità delle applicazioni distribuite alla latenza di rete.

Tenere presenti queste considerazioni quando si decide di distribuire le risorse tra zone di disponibilità:

• Latenza tra macchine virtuali in una zona
• Latenza tra macchine virtuali tra le zone scelte
• Disponibilità degli stessi servizi di Azure (tipi di vm) nelle zone scelte

Esempio di distribuzione attiva/inattiva

In questa distribuzione di esempio lo stato attivo/passivo si riferisce allo stato del servizio dell'applicazione all'interno delle zone. Nel livello applicazione, tutti e quattro i server applicazioni attivi del sistema SAP si trovano nella zona 1. Un altro set di quattro server applicazioni passivi è integrato nella zona 2, ma viene arrestato. Vengono attivati solo quando sono necessari.

I cluster a due nodi per Central Services e i servizi di database vengono estesi tra due zone. Se la zona 1 ha esito negativo, Central Services e i servizi di database vengono eseguiti nella zona 2. I server applicazioni passivi nella zona 2 vengono attivati. Con tutti i componenti di questo sistema SAP ora si trovano nella stessa zona, la latenza di rete è ridotta a icona.

Esempio di distribuzione attiva/attiva

In una distribuzione attiva/attiva , due set di server applicazioni vengono compilati in due zone. All'interno di ogni zona, due server applicazioni in ogni set di server sono inattivi, perché vengono arrestati. Di conseguenza, sono presenti server applicazioni attivi in entrambe le zone durante le normali operazioni.

Central Services e i servizi di database vengono eseguiti nella zona 1. I server applicazioni nella zona 2 potrebbero avere una latenza di rete più lunga quando si connettono a Central Services e ai servizi di database a causa della distanza fisica tra le zone.

Se la zona 1 passa offline, i servizi centrali e i servizi di database ese verificano il failover nella zona 2. È possibile portare online i server applicazioni inattivi per fornire capacità completa per l'elaborazione delle applicazioni.

Considerazioni sul ripristino di emergenza

Ogni livello nello stack di applicazioni SAP usa un approccio diverso per garantire la protezione del ripristino di emergenza. Per informazioni dettagliate sulle strategie di ripristino di emergenza e sull'implementazione, vedere Panoramica del ripristino di emergenza e linee guida sull'infrastruttura per il carico di lavoro SAP e le linee guida per il ripristino di emergenza per l'applicazione SAP.

Considerazioni sulla gestione e sulle operazioni

Per mantenere il sistema in esecuzione nell'ambiente di produzione, prendere in considerazione i punti seguenti.

Centro di Azure per soluzioni SAP

Il Centro di Azure per soluzioni SAP è una soluzione end-to-end che consente di creare ed eseguire sistemi SAP come carico di lavoro unificato in Azure e offre una base più semplice per l'innovazione. Inoltre, l'esperienza di distribuzione guidata del Centro di Azure per soluzioni SAP crea i componenti di calcolo, archiviazione e rete necessari per eseguire il sistema SAP. Consente quindi di automatizzare l'installazione del software SAP in base alle procedure consigliate microsoft. È possibile sfruttare le funzionalità di gestione per sistemi SAP nuovi e esistenti. Per altre informazioni, vedere Centro di Azure per soluzioni SAP.

Se è necessario un maggiore controllo sugli eventi di manutenzione o sull'isolamento hardware, per prestazioni o conformità, è consigliabile distribuire le macchine virtuali in host dedicati.

Backup

I database sono carichi di lavoro critici che richiedono un obiettivo del punto di ripristino basso (RPO) e la conservazione a lungo termine.

• Per SAP in SQL Server, un approccio consiste nell'usare Backup di Azure per eseguire il backup di database di SQL Server eseguiti nelle macchine virtuali. Un'altra opzione consiste nell'usare gli snapshot File di Azure per eseguire il backup dei file di database di SQL Server.

• Per SAP in Oracle/Windows, vedere la sezione "Backup/ripristino" in Distribuzione DBMS di macchine virtuali di Azure per SAP.

• Per altri database, vedere le raccomandazioni di backup per il provider di database. Se il database supporta il servizio Copia Shadow del volume di Windows , usare gli snapshot vss per i backup coerenti con l'applicazione.

Gestione delle identità

Usare un sistema di gestione delle identità centralizzato come Microsoft Entra ID e servizi di Dominio di Active Directory (AD DS) per controllare l'accesso alle risorse a tutti i livelli:

• Fornire l'accesso alle risorse di Azure usando il controllo degli accessi in base al ruolo di Azure.

• Concedere l'accesso alle macchine virtuali di Azure usando Lightweight Directory Access Protocol (LDAP), Microsoft Entra ID, Kerberos o un altro sistema.

Supportare l'accesso all'interno delle applicazioni stesse usando i servizi forniti da SAP. In alternativa, usare OAuth 2.0 e Microsoft Entra ID.

Monitoraggio

Per ottimizzare la disponibilità e le prestazioni delle applicazioni e dei servizi in Azure, usare Monitoraggio di Azure, una soluzione completa per la raccolta, l'analisi e l'esecuzione dei dati di telemetria dagli ambienti cloud e locali. Monitoraggio di Azure mostra come le applicazioni eseguono e identificano in modo proattivo i problemi che li interessano e le risorse da cui dipendono. Per le applicazioni SAP eseguite in SAP HANA e altre soluzioni di database principali, vedere Monitoraggio di Azure per soluzioni SAP per informazioni su come Monitoraggio di Azure per SAP può aiutare a gestire la disponibilità e le prestazioni dei servizi SAP.

Considerazioni relative alla sicurezza

SAP ha un proprio motore di gestione utenti (UME) per controllare l'accesso e l'autorizzazione basati sui ruoli all'interno dell'applicazione e dei database SAP. Per indicazioni dettagliate sulla sicurezza delle applicazioni, vedere SAP NetWeaver Security Guide (Guida alla sicurezza di SAP NetWeaver).

Per una maggiore sicurezza di rete, è consigliabile usare una rete perimetrale che usa un'appliance virtuale di rete per creare un firewall davanti alla subnet per Web Dispatcher.

È possibile distribuire un'appliance virtuale di rete per filtrare il traffico tra reti virtuali, ma non inserirlo tra l'applicazione SAP e il database. Controllare anche le regole di routing configurate nella subnet ed evitare di indirizzare il traffico a un'appliance virtuale di rete a istanza singola. Questa operazione può causare tempi di inattività di manutenzione e errori di rete o nodi in cluster.

Per la sicurezza dell'infrastruttura, vengono crittografati sia i dati in transito sia quelli inattivi. Per informazioni sulla sicurezza di rete, vedere la sezione "Raccomandazioni sulla sicurezza" in Pianificazione e implementazione di Azure Macchine virtuali per SAP NetWeaver. Questo articolo specifica anche le porte di rete da aprire nei firewall per consentire la comunicazione dell'applicazione.

È possibile usare Crittografia dischi di Azure per crittografare i dischi delle macchine virtuali Windows. Questo servizio usa la funzionalità BitLocker di Windows per fornire la crittografia del volume per il sistema operativo e i dischi dati. La soluzione può essere usata anche con Azure Key Vault per semplificare il controllo e la gestione dei segreti e delle chiavi di crittografia dei dischi nella sottoscrizione dell'insieme di credenziali delle chiavi. I dati nei dischi delle macchine virtuali vengono crittografati inattivi nell'archiviazione di Azure.

Per la crittografia dei dati inattivi, SQL Server Transparent Data Encryption (TDE) crittografa SQL Server, database SQL di Azure e i file di dati di Azure Synapse Analytics. Per altre informazioni, vedere SQL Server Azure Macchine virtuali distribuzione DBMS per SAP NetWeaver.

Per monitorare le minacce dall'interno e dall'esterno del firewall, valutare la possibilità di distribuire Microsoft Sentinel (anteprima). La soluzione offre funzionalità di rilevamento e analisi continue delle minacce per i sistemi SAP distribuiti in Azure, in altri cloud o in locale. Per indicazioni sulla distribuzione, vedere Distribuire Il monitoraggio delle minacce per SAP in Microsoft Sentinel.

Come sempre, gestire gli aggiornamenti e le patch di sicurezza per proteggere gli asset di informazioni. Prendere in considerazione l'uso di un approccio di automazione end-to-end per questa attività.

Considerazioni sui costi

Usare il calcolatore dei prezzi di Azure per stimare i costi.

Per altre informazioni, vedere la sezione sui costi in Microsoft Azure Well-Architected Framework.

Se il carico di lavoro richiede più memoria e un minor numero di CPU, prendere in considerazione l'uso di una delle dimensioni della macchina virtuale vCPU vincolate per ridurre i costi di licenza software addebitati per ogni vCPU.

Macchine virtuali

Questa architettura usa macchine virtuali per il livello applicazione e il livello di database. Il livello SAP NetWeaver usa macchine virtuali Windows per eseguire servizi e applicazioni SAP. Il livello di database esegue AnyDB come database, ad esempio SQL Server, Oracle o IBM DB2. Le macchine virtuali vengono usate anche come jumpbox per la gestione.

Esistono diverse opzioni di pagamento per le macchine virtuali:

• Per i carichi di lavoro che non hanno tempi prevedibili di completamento o consumo di risorse, prendere in considerazione l'opzione con pagamento in base al consumo.

• Prendere in considerazione l'uso delle prenotazioni di Azure se è possibile eseguire il commit nell'uso di una macchina virtuale per un periodo di un anno o di tre anni. Le prenotazioni delle macchine virtuali possono ridurre significativamente i costi. È possibile pagare fino al 72% del costo di un servizio con pagamento in base al consumo.

Usare le macchine virtuali spot di Azure per eseguire carichi di lavoro che possono essere interrotti e non richiedono il completamento entro un intervallo di tempo predeterminato o un contratto di servizio. Azure distribuisce macchine virtuali spot quando è disponibile la capacità e le rimuove quando è necessaria la capacità. I costi associati alle macchine virtuali spot sono inferiori rispetto ad altre macchine virtuali. Prendere in considerazione le macchine virtuali spot per questi carichi di lavoro:

• Scenari di elaborazione ad alte prestazioni, processi di elaborazione batch o applicazioni di rendering visivo
• Ambienti di test, tra cui l'integrazione continua e i carichi di lavoro di recapito continuo
• Applicazioni senza stato su larga scala

Le istanze di macchine virtuali riservate di Azure possono ridurre il costo totale di proprietà combinando le tariffe delle istanze di macchine virtuali riservate di Azure con una sottoscrizione con pagamento in base al consumo, in modo da poter gestire i costi tra carichi di lavoro prevedibili e variabili. Per altre informazioni, vedere Istanze di macchine virtuali riservate di Azure.

Load Balancer

In questo scenario, Load Balancer viene usato per distribuire il traffico alle macchine virtuali nella subnet del livello applicazione.

Vengono addebitati solo il numero di regole di bilanciamento del carico e in uscita configurate, oltre ai dati elaborati tramite il servizio di bilanciamento del carico. Le regole NAT (Network Address Translation) in ingresso sono gratuite. Non è previsto alcun addebito orario per Load Balancer Standard quando non sono configurate regole.

ExpressRoute

In questa architettura ExpressRoute è il servizio di rete usato per creare connessioni private tra una rete locale e reti virtuali di Azure.

Tutto il trasferimento dei dati in ingresso è gratuito. Tutto il trasferimento dei dati in uscita viene addebitato in base a una tariffa pre-determinata. Per altre informazioni, vedere Prezzi di ExpressRoute di Azure.

Community

Le community possono rispondere alle domande ed essere utili per configurare correttamente la distribuzione. Prendere in considerazione queste risorse:

• Blog sull'esecuzione di applicazioni SAP nel blog di Microsoft Platform
• Supporto della community di Azure
• Community SAP
• Stack Overflow per SAP

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

• Ben Trinh | Architetto principale

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Per altre informazioni e per esempi di carichi di lavoro SAP che usano alcune delle stesse tecnologie di questa architettura, vedere gli articoli seguenti:

• Guida alla pianificazione e all'implementazione di Macchine virtuali di Azure per SAP NetWeaver
• Usare Azure per ospitare ed eseguire scenari di carico di lavoro SAP

Risorse correlate

• Eseguire carichi di lavoro di produzione SAP usando un database Oracle in Azure