SAP S/4HANA in Linux su Azure

Questa guida presenta un set di procedure comprovate per l'esecuzione di S/4HANA e Suite in HANA in un ambiente a disponibilità elevata che supporta il ripristino di emergenza in Azure. Le informazioni Fiori si applicano solo alle applicazioni S/4HANA.

Architettura

Scaricare un file di Visio di questa architettura.

Questa guida descrive un tipico sistema di produzione. Questa architettura usa diverse dimensioni di macchina virtuale. Per soddisfare le esigenze dell'organizzazione, è possibile modificare le dimensioni o ridurre questa configurazione a una singola macchina virtuale.

In questa guida il layout di rete è semplificato per illustrare i principi architetturali. Non rappresenta una rete aziendale completa.

L'architettura usa i componenti seguenti. Alcuni servizi condivisi sono facoltativi.

Rete virtuale di Azure. Il servizio Rete virtuale connette le risorse di Azure tra loro con sicurezza avanzata. In questa architettura una rete virtuale si connette a un ambiente locale tramite un gateway distribuito nell'hub di una topologia hub-spoke. Lo spoke è la rete virtuale usata per le applicazioni SAP e i livelli di database.

Peering di rete virtuale. Questa architettura utilizza più reti virtuali interconnesse tramite peering. Questa topologia fornisce la segmentazione di rete e l'isolamento per i servizi distribuiti in Azure. Il peering connette le reti in modo trasparente tramite la rete backbone Microsoft e non comporta una riduzione delle prestazioni se viene implementata all'interno di una singola area. Le subnet separate vengono usate per ogni livello, incluso il livello applicazione (SAP NetWeaver) e il livello di database e per i componenti condivisi, ad esempio la jump box e Windows Server Active Directory.

VM. Questa architettura organizza le macchine virtuali che eseguono Linux in gruppi per il livello applicazione e il livello di database nei modi seguenti:

• Livello applicazione. Questo livello architetturale include il pool di server front-end Fiori, il pool sap Web Dispatcher, il pool di server applicazioni e il cluster SAP Central Services. Per l'alta disponibilità dei servizi centrali su Azure in esecuzione su macchine virtuali Linux, è necessario un servizio di condivisione file di rete ad alta disponibilità, ad esempio condivisioni file NFS (Network File System) in Azure Files, Azure NetApp Files, server NFS in cluster o SIOS Protection Suite per Linux. Per configurare una condivisione file a disponibilità elevata per il cluster Central Services in Red Hat Enterprise Linux (RHEL), è possibile configurare GlusterFS in macchine virtuali di Azure che eseguono RHEL. In SUSE Linux Enterprise Server (SLES) 15 SP1 e versioni successive o SLES for SAP Applications è possibile usare dischi condivisi di Azure in un cluster Pacemaker come dispositivo di isolamento per ottenere la disponibilità elevata.

• SAP HANA. Il livello di database usa due o più macchine virtuali Linux in un cluster per ottenere disponibilità elevata in una distribuzione con scalabilità orizzontale. La replica di sistema HANA (HSR) viene usata per replicare il contenuto tra sistemi HANA primario e secondario. Il clustering Linux viene usato per rilevare gli errori di sistema e facilitare il failover automatico. È necessario usare un meccanismo di isolamento basato su archiviazione o basato sul cloud per garantire che il sistema non riuscito sia isolato o arrestato per evitare un cluster partizionato. Nelle distribuzioni con scalabilità orizzontale di HANA è possibile ottenere la disponibilità elevata del database usando una delle opzioni seguenti:

  • Configurare i nodi di standby HANA usando Azure NetApp Files senza il componente clustering Linux.

  • Aumentare il numero di istanze senza nodi di standby usando Archiviazione Premium di Azure. Usare il clustering Linux per il failover.

• Azure Bastion. Questo servizio consente di connettersi a una macchina virtuale usando il browser e il portale di Azure oppure usando il client NATIVE Secure Shell (SSH) o RdP (Remote Desktop Protocol) installato nel computer locale. Se per l'amministrazione vengono usati solo RDP e SSH, è consigliabile usare Azure Bastion. Se si usano altri strumenti di gestione, ad esempio SQL Server Management Studio o un front-end SAP, usare una jump box tradizionale auto-distribuita.

Servizio DNS privato.Azure Private DNS fornisce un affidabile e sicuro servizio DNS per la tua rete virtuale. DNS privato di Azure 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 aumentare la disponibilità, usare Azure Load Balancer Standard. Load Balancer Standard offre un livello di sicurezza per impostazione predefinita. Le macchine virtuali che si trovano dietro Load Balancer Standard non hanno connettività Internet in uscita. Per abilitare Internet in uscita nelle macchine virtuali, è necessario aggiornare la configurazione Load Balancer Standard. È anche possibile usare il gateway NAT di Azure per ottenere la connettività in uscita. Per le applicazioni SAP basate sul Web ad alta disponibilità, utilizzare il SAP Web Dispatcher predefinito o un altro bilanciatore di carico disponibile in commercio. Basare la selezione su:

• Tipo di traffico, ad esempio traffico HTTP o interfaccia utente grafica SAP (GUI).
• Funzionalità di rete necessarie, ad esempio la terminazione SSL (Secure Sockets Layer).

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

• Advanced Business Application Programming (ABAP) SAP Central Services (ASCS)
• Server di replica accodamento

Questi due componenti possono condividere un servizio di bilanciamento del carico per semplificare la soluzione.

Load Balancer Standard supporta anche i cluster SAP con identificatore di sistema multiplo (multi-SID). Questa funzionalità consente a più sistemi SAP in SLES o RHEL di condividere un'infrastruttura a disponibilità elevata comune per ridurre i costi. È consigliabile valutare il risparmio sui costi ed evitare di inserire troppi sistemi in un cluster. Azure supporta fino a cinque SID per ogni cluster.

Gateway dell'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, noto come OSI (Open Systems Interconnect) layer 4, usando Transmission Control Protocol e User Datagram Protocol. Instradano il traffico basandosi sull'indirizzo IP e sulla porta di origine per raggiungere un indirizzo IP e una porta di destinazione. Il gateway applicativo può prendere decisioni di routing basate su attributi aggiuntivi di una richiesta HTTP, come ad esempio il percorso URI o le intestazioni dell'host. Questo tipo di routing è noto come bilanciamento del carico a livello di applicazione, o livello 7 OSI. S/4HANA fornisce servizi di applicazioni Web tramite Fiori. È possibile bilanciare il carico di questo front-end Fiori, costituito da app Web, usando gateway applicazione. Se si utilizzano indirizzi IP pubblici, è necessario assicurarsi che utilizzino lo SKU dell'indirizzo IP standard. Evitate lo SKU dell'indirizzo IP di base perché verrà dismesso il 30 settembre 2025.

Portale Un gateway connette reti distinte ed estende la rete locale a una rete virtuale di Azure. Azure ExpressRoute è il servizio di Azure consigliato per la creazione di connessioni private che non passano tramite La rete Internet pubblica. È anche possibile usare una connessione da sito a sito . Per ridurre la latenza, usare Copertura globale expressRoute o ExpressRoute FastPath.

Gateway con ridondanza della zona. È possibile distribuire gateway ExpressRoute o di rete privata virtuale (VPN) tra zone per proteggersi dagli errori della zona. Questa architettura utilizza gateway di rete virtuale ridondanti a zona per la resilienza anziché una distribuzione a livello di zona basata sulla stessa zona di disponibilità.

Gruppo di posizionamento di prossimità. Questo gruppo logico inserisce un vincolo nelle macchine virtuali distribuite in un set di disponibilità o in un set di scalabilità di macchine virtuali. Un gruppo di posizionamento di prossimità consente di applicare la corilevazione assicurandosi che le macchine virtuali vengano distribuite nello stesso data center. Questa configurazione riduce la distanza fisica tra le risorse per ridurre al minimo la latenza dell'applicazione.

Gruppi di sicurezza di rete (NSG). Per limitare il traffico in ingresso, in uscita e all'interno della subnet in una rete virtuale, è possibile creare gruppi di sicurezza della rete NSGs.

Gruppi di sicurezza delle applicazioni. Per definire criteri di sicurezza di rete con granularità fine basati su carichi di lavoro e incentrati sulle applicazioni, usare gruppi di sicurezza delle applicazioni anziché indirizzi IP espliciti. È possibile raggruppare le macchine virtuali in base al nome e alle applicazioni sicure filtrando il traffico da segmenti attendibili della rete.

Azure Storage 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 variano 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 altre informazioni su come eseguire SAP NetWeaver nelle macchine virtuali, vedere La guida alla pianificazione e all'implementazione di macchine virtuali di Azure. La guida si applica anche alle distribuzioni SAP S/4HANA.

Per altre informazioni sul supporto SAP per i tipi di macchine virtuali di Azure e per le metriche di velocità effettiva, vedere la nota SAP 1928533. Per accedere alle note SAP, è necessario un account SAP Service Marketplace. Per un elenco delle macchine virtuali di Azure certificate per il database HANA, vedere La directory hardware SAP HANA certificata e supportata.

SAP Dispatcher Web

Il componente Web Dispatcher viene usato per il bilanciamento del carico del traffico SAP tra i server applicazioni SAP. Per ottenere un'elevata disponibilità di SAP Web Dispatcher, Azure Load Balancer implementa un cluster di failover o la configurazione parallela di Web Dispatcher. Per le comunicazioni con connessione Internet, una soluzione autonoma nella rete perimetrale è l'architettura consigliata per soddisfare i requisiti di sicurezza. Il dispatcher Web incorporato in ASCS è una configurazione avanzata. Se si utilizza questa configurazione, considerare un adeguato dimensionamento a causa del carico di lavoro aggiuntivo sull'ASCS.

Server front-end Fiori (FES)

Questa architettura soddisfa più requisiti e presuppone che si usi il modello Fiori FES incorporato. Tutti i componenti tecnologici vengono installati direttamente nel sistema S/4, quindi ogni sistema S/4 ha il proprio launchpad Fiori. Il sistema S/4 gestisce la configurazione a disponibilità elevata per questo modello di distribuzione. Questo approccio elimina la necessità di clustering o macchine virtuali aggiuntive. Per questo motivo, il diagramma dell'architettura non include il componente FES.

Per altre informazioni sulle opzioni di distribuzione, vedere Le opzioni di distribuzione sap Fiori e le raccomandazioni relative al panorama del sistema. Per semplicità e prestazioni, le versioni software tra i componenti della tecnologia Fiori e le applicazioni S/4 sono strettamente accoppiate. Questa configurazione rende una distribuzione hub adatta solo per alcuni casi d'uso specifici.

Se si usa la distribuzione dell'hub FES, FES è un componente aggiuntivo nello stack ABAP classico di SAP NetWeaver. Configurare la disponibilità elevata allo stesso modo in cui si protegge uno stack di applicazioni ABAP a tre livelli con funzionalità cluster o multiple-host. Usare un livello di database del server standby, un livello ASCS clusterizzato con HA NFS per l'archiviazione condivisa e almeno due server applicativi. Il traffico viene bilanciato tramite una coppia di istanze di Web Dispatcher che possono essere raggruppate o parallele. Per le app Fiori con connessione Internet, è consigliabile una distribuzione dell'hub FES nella rete perimetrale. Usa il Web Application Firewall di Azure su Application Gateway come componente critico per deviare le minacce. Usare Microsoft Entra ID con Security Assertion Markup Language per l'autenticazione degli utenti e l'accesso unico per SAP Fiori.

Scaricare un file di Visio di questa architettura.

Per altre informazioni, vedere Connessioni Internet in ingresso e in uscita per SAP in Azure.

Pool di server di applicazioni

Per gestire i gruppi di accesso per i server applicazioni ABAP, usare i codici di transazione seguenti:

• SMLG: Bilancia il carico degli utenti di accesso.
• SM61: Gestire i gruppi di server batch.
• RZ12: Gestire i gruppi RFC (Remote Function Call).

Queste transazioni si basano sulla funzionalità di bilanciamento del carico nel server messaggi di Central Services per distribuire sessioni e carichi di lavoro in ingresso nel pool di server applicazioni SAP che gestiscono il traffico SAP GUI e RFC.

Il cluster dei servizi centrali SAP

I SAP Central Services includono una singola istanza del server dei messaggi e del servizio di replica di accodamento. A differenza dei processi di lavoro dei server applicazioni, questi componenti sono singoli punti di errore nello stack di applicazioni SAP. È possibile distribuire Central Services in una singola macchina virtuale quando il contratto di servizio di disponibilità della macchina virtuale a istanza singola di Azure soddisfa le esigenze. Se il contratto di servizio richiede una disponibilità più elevata, è necessario distribuire questi servizi in un cluster a disponibilità elevata. Per ulteriori informazioni, vedere Central Services nel livello dei server delle applicazioni.

Rete

Questa architettura usa una topologia hub-spoke in cui la rete virtuale hub funge da punto centrale di connettività a una rete locale. Gli spoke sono reti virtuali che eseguono il peering con l'hub. È possibile usare i "spokes" per isolare i carichi di lavoro. Il traffico scorre tra il data center locale e l'hub attraverso una connessione gateway.

Schede di interfaccia di rete

Le distribuzioni SAP locali tradizionali implementano più schede di interfaccia di rete (NIC) per computer per separare il traffico amministrativo dal traffico aziendale. In Azure la rete virtuale è una rete software-defined che instrada tutto il traffico attraverso un'unica infrastruttura di rete. Di conseguenza, non sono necessarie più schede di interfaccia di rete per motivi di prestazioni. Se l'organizzazione deve separare il traffico, è possibile distribuire più schede di interfaccia di rete per ogni macchina virtuale, connettere ogni scheda di interfaccia di rete a una subnet diversa, quindi 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 è allineato alla procedura consigliata da SAP per l'uso dei nomi host virtuali per le installazioni nella nota SAP 962955.

Subnet e gruppi di sicurezza di rete

Questa architettura divide lo spazio degli indirizzi della 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. Questo approccio semplifica la protezione dei server applicazioni 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 fornisce un controllo granulare sui server. Configurare i gruppi di sicurezza di rete usando il portale di Azure, Azure PowerShell o l'interfaccia della riga di comando di Azure.

Copertura globale di ExpressRoute

Se l'ambiente di rete include due o più circuiti ExpressRoute, Copertura globale di ExpressRoute consente di ridurre gli hop di rete e ridurre la latenza. Questa tecnologia è un peering delle rotte del Border Gateway Protocol configurato tra due o più circuiti ExpressRoute per unire due domini di routing ExpressRoute. Copertura globale riduce la latenza quando il traffico di rete attraversa più circuiti ExpressRoute. È disponibile solo per il peering privato nei circuiti ExpressRoute.

Global Reach non supporta le modifiche apportate agli elenchi di controllo di accesso di rete o ad altri attributi. Tutte le rotte apprese da un circuito ExpressRoute, dall'ambiente locale o da Azure, vengono annunciate attraverso il peering del circuito ad altri circuiti ExpressRoute. È consigliabile configurare il filtro del traffico di rete locale per limitare l'accesso alle risorse.

FastPath

FastPath implementa scambi di Microsoft Edge nel punto di ingresso della rete di Azure. FastPath riduce gli hop di rete per la maggior parte dei pacchetti di dati. Di conseguenza, FastPath riduce la latenza di rete, migliora le prestazioni dell'applicazione ed è la configurazione predefinita per le nuove connessioni ExpressRoute ad Azure.

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 una rete virtuale connessa a ExpressRoute con altre reti virtuali, il traffico dalla rete locale alle altre reti virtuali spoke viene instradato attraverso il gateway di rete virtuale. Per risolvere questo problema, connettere tutte le reti virtuali direttamente al circuito ExpressRoute.

Servizi di bilanciamento del carico

SAP Web Dispatcher gestisce il bilanciamento del carico del traffico HTTP e HTTPS verso un pool di server applicazioni SAP. Questo bilanciatore del carico software fornisce servizi a livello di applicazione, noto come livello 7 nel modello di rete ISO, che sono in grado di effettuare la terminazione SSL e altre funzioni di alleggerimento.

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 un indirizzo IP di origine, una porta di origine, un indirizzo IP di destinazione, una porta di destinazione e un tipo di protocollo. 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. Load Balancer Standard è sicuro per impostazione predefinita e nessuna macchina virtuale dietro Load Balancer Standard dispone di connettività Internet in uscita. Per abilitare Internet in uscita nelle macchine virtuali, è necessario modificare la configurazione Load Balancer Standard.

Per il traffico dei client SAP GUI che si connettono a un server SAP tramite il protocollo DIAG (Dynamic Information and Action Gateway) o RFC, il server dei messaggi dei servizi centrali bilancia il carico tramite i gruppi di accesso del server applicazioni SAP. Non è necessario alcun servizio di bilanciamento del carico aggiuntivo.

Immagazzinamento

Alcuni clienti usano l'archiviazione standard per i server applicazioni. Poiché i dischi gestiti standard non sono supportati, è consigliabile usare l'unità SSD Premium di Azure o Azure NetApp Files in tutti gli scenari. Un aggiornamento recente alla nota SAP 2015553 esclude l'uso dell'archiviazione HDD Standard di Azure e dell'archiviazione SSD Standard di Azure per alcuni casi d'uso specifici.

Poiché i server applicazioni non ospitano dati aziendali, è anche possibile usare i dischi P4 e P6 Premium più piccoli per gestire i costi. Per le applicazioni SAP, è consigliabile usare dischi SSD v1, SSD v2 o Ultra di Azure. Per comprendere in che modo il tipo di archiviazione influisce sul contratto di servizio per la disponibilità della macchina virtuale, vedere Contratti di servizio per i servizi online. Per gli scenari a disponibilità elevata, le funzionalità del disco condiviso di Azure sono disponibili in Unità SSD Premium di Azure e Archiviazione su disco Ultra di Azure. Per altre informazioni, vedere Dischi gestiti di Azure e tipi di dischi gestiti di Azure.

È possibile usare dischi condivisi di Azure con Windows Server, SLES 15 SP1 e versioni successive o SLES per SAP. Quando si usa un disco condiviso di Azure nei cluster Linux, il disco condiviso di Azure funge da isolamento di un dispositivo a blocchi di nodi non riuscito. In uno scenario di partizionamento di rete del cluster, fornisce un voto di quorum. Questo disco condiviso non ha un file system e non supporta le scritture simultanee da più macchine virtuali membro del cluster.

Azure NetApp Files include funzionalità di condivisione file predefinite per NFS e SMB.

Per gli scenari di condivisione NFS, Azure NetApp Files fornisce disponibilità elevata per le condivisioni NFS che possono essere usate per /hana/shared, /hana/data e /hana/log volumi. Per la garanzia di disponibilità, vedere Contratti di servizio per i servizi online. Se si usano condivisioni NFS basate su Azure NetApp Files per i /hana/data volumi e /hana/log , è necessario usare il protocollo NFS v4.1. Per il /hana/shared volume, è supportato il protocollo NFS v3.

Per l'archivio dati di backup, è consigliabile usare i livelli di accesso a bassa frequenza e archivio di Azure. Questi livelli di archiviazione sono modi convenienti per archiviare dati di lunga durata a cui si accede raramente. Prendere in considerazione anche l'uso del livello Azure NetApp Files Standard come destinazione di backup o come opzione di backup di Azure NetApp Files. Per un disco gestito, il livello di dati di backup consigliato è il livello di accesso freddo o di archiviazione di Azure.

Il livello Ultra Disk Storage e Azure NetApp Files Ultra riducono significativamente la latenza del disco e migliorano le prestazioni delle applicazioni critiche e dei server di database SAP.

SSD Premium v2 è progettato per carichi di lavoro critici per le prestazioni, ad esempio SAP. Per altre informazioni sui vantaggi e sulle limitazioni di questa soluzione di archiviazione, vedere Distribuire un'unità SSD Premium v2.

Considerazioni sulle prestazioni

I server applicazioni SAP comunicano costantemente con i server di database. Per le applicazioni critiche per le prestazioni eseguite in qualsiasi piattaforma di database, incluso SAP HANA, abilitare l'acceleratore di scrittura per il volume di log se si usa SSD Premium v1. Questo approccio può migliorare la latenza di scrittura dei log. Ssd Premium v2 non usa l'acceleratore di scrittura. 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'hyper-threading, le istanze di macchine virtuali con quattro o più vCPU supportano la rete accelerata.

Per altre informazioni sui requisiti di prestazioni di SAP HANA, vedere la nota SAP 1943937.

Per ottenere operazioni di input/output elevate al secondo (IOPS) e velocità effettiva della larghezza di banda del disco, seguire le procedure comuni per l'ottimizzazione delle prestazioni del volume di archiviazione. Ad esempio, combinare più dischi per creare un volume a strisce può migliorare le prestazioni di input/output (I/O). L'abilitazione della cache di lettura nel contenuto di archiviazione che cambia raramente può anche velocizzare il recupero dei dati. Per altre informazioni, vedere Configurazioni di archiviazione delle macchine virtuali di Azure sap HANA.

SSD Premium v2 è progettato per carichi di lavoro critici per le prestazioni, ad esempio SAP. Per altre informazioni sui vantaggi, le limitazioni e gli scenari di uso ottimali, vedere Tipi di dischi gestiti di Azure.

Archiviazione su disco Ultra è una nuova generazione di archiviazione che soddisfa un numero elevato di operazioni di I/O al secondo e le richieste di larghezza di banda di trasferimento di applicazioni come SAP HANA. È possibile modificare dinamicamente le prestazioni dei dischi Ultra e configurare in modo indipendente metriche come IOPS e MBps senza riavviare la macchina virtuale. È consigliabile usare l'archiviazione su disco Ultra anziché l'acceleratore di scrittura quando possibile.

Alcune applicazioni SAP richiedono una comunicazione frequente con il database. A causa della distanza, la latenza di rete tra i livelli dell'applicazione e del database può influire negativamente sulle prestazioni dell'applicazione. I gruppi di posizionamento di prossimità di Azure impostano un vincolo di posizionamento per le macchine virtuali distribuite nei set di disponibilità. All'interno del costrutto logico di un gruppo, la condivisione e le prestazioni sono favorite rispetto alla scalabilità, alla disponibilità e ai costi. I gruppi di posizionamento di prossimità possono migliorare notevolmente l'esperienza utente per la maggior parte delle applicazioni SAP.

Il posizionamento di un'appliance virtuale di rete tra l'applicazione e i livelli di database di qualsiasi stack di applicazioni SAP non è supportato. La NVA richiede una quantità notevole di tempo per elaborare i pacchetti di dati. Di conseguenza, rallenta in modo inaccettabile le prestazioni dell'applicazione.

È anche consigliabile prendere in considerazione le prestazioni quando si distribuiscono risorse con zone di disponibilità, che possono migliorare la disponibilità del servizio. Prendere in considerazione la creazione di un profilo di latenza di rete chiaro tra tutte le zone di un'area di destinazione. Questo approccio consente di decidere il posizionamento delle risorse per la latenza minima tra le zone. Per creare questo profilo, eseguire un test distribuendo macchine virtuali di piccole dimensioni in ogni zona. Gli strumenti consigliati per il test includono PsPing e Iperf. Dopo il test, rimuovere queste macchine virtuali. Per uno strumento di test della latenza di rete di dominio pubblico da utilizzare, consulta il test della latenza della zona di disponibilità.

Azure NetApp Files offre funzionalità di prestazioni uniche che consentono l'ottimizzazione in tempo reale per soddisfare le esigenze degli ambienti SAP più esigenti. Per considerazioni sulle prestazioni quando si usa Azure NetApp Files, vedere Dimensionamento per il database HANA in Azure NetApp Files.

Considerazioni sulla scalabilità

A livello di applicazione SAP, Azure offre un'ampia gamma di dimensioni delle VM per la scalabilità verso l'alto e verso l'esterno. Per un elenco completo, vedere Applicazioni SAP in Azure: prodotti supportati e tipi di VM di Azure nella nota SAP 1928533. Più tipi di vm sono continuamente certificati, quindi è possibile aumentare o ridurre le prestazioni nella stessa distribuzione cloud.

A livello di database, questa architettura esegue applicazioni SAP S/4HANA in macchine virtuali di Azure con scalabilità fino a 24 terabyte (TB) in un'unica istanza. Se il carico di lavoro supera le dimensioni massime della macchina virtuale, è possibile usare una configurazione a più nodi per un massimo di 96 TB (quattro istanze di 24 TB) per le applicazioni di elaborazione delle transazioni online. Per altre informazioni, vedere La directory hardware di SAP HANA certificata e supportata.

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 Contratti di servizio per i servizi online. Per aumentare la disponibilità del servizio in Azure, distribuire le risorse delle macchine virtuali usando set di scalabilità di macchine virtuali di Azure, che offre orchestrazione flessibile, zone di disponibilità e set di disponibilità.

Il modello di distribuzione dei set di disponibilità a livello di area di Azure è un'opzione supportata. È tuttavia consigliabile adottare i set di scalabilità di macchine virtuali con il modello di zone di disponibilità per le nuove distribuzioni SAP per migliorare la disponibilità e aumentare la flessibilità di distribuzione.

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

Approcci alla distribuzione

In 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 (una configurazione del dominio di errore), zone di disponibilità e set di disponibilità, per migliorare la disponibilità delle risorse.

Man mano che le distribuzioni dei clienti in Azure sono aumentate nel corso degli anni, Microsoft ha migliorato i modelli di distribuzione delle macchine virtuali di Azure per includere set di scalabilità di macchine virtuali per garantire elasticità e resilienza del cloud. Considerando le opzioni di distribuzione disponibili, è consigliabile usare la distribuzione di zona del set di scalabilità flessibile di Azure per tutte le nuove distribuzioni. Per altre informazioni sulla distribuzione tra zone, all'interno di una singola zona e in aree senza zone, vedere Architettura e scenari a disponibilità elevata per SAP NetWeaver.

Web Dispatcher nel livello dei server delle applicazioni

È possibile ottenere disponibilità elevata usando istanze ridondanti di Web Dispatcher. Per altre informazioni, vedere SAP Web Dispatcher. Il livello di disponibilità dipende dalle dimensioni dell'applicazione che si basa su Web Dispatcher. Nelle distribuzioni di piccole dimensioni con pochi problemi di scalabilità, è possibile colocare Web Dispatcher con le macchine virtuali ASCS. Questo approccio consente di risparmiare sulla manutenzione indipendente del sistema operativo e ottenere la disponibilità elevata contemporaneamente.

Central Services nel livello dei server di applicazioni

Per la disponibilità elevata di Central Services nelle macchine virtuali Linux di Azure, usare l'estensione a disponibilità elevata appropriata per la distribuzione Linux selezionata. È consuetudine inserire i file system condivisi nell'archiviazione NFS a disponibilità elevata usando il dispositivo a blocchi replicati distribuito SUSE o Red Hat GlusterFS. Per offrire un NFS a disponibilità elevata ed eliminare la necessità di un cluster NFS, è possibile usare altre soluzioni convenienti o affidabili come NFS su File di Azure o Azure NetApp Files. Le condivisioni di Azure NetApp Files possono ospitare i file di dati e di log di SAP HANA. Questa configurazione abilita il modello di distribuzione con scalabilità orizzontale HANA con nodi standby, mentre NFS su File di Azure è ideale per la condivisione di file non di database a disponibilità elevata.

NFS su File di Azure supporta ora le condivisioni file a disponibilità elevata sia per SLES che per RHEL. Questa soluzione è ideale per le condivisioni file a disponibilità elevata, ad esempio /sapmnt e /saptrans nelle installazioni SAP.

Azure NetApp Files supporta l'alta disponibilità di ASCS su SLES. Per altre informazioni su ASCS in RHEL HA, vedere SIOS Protection Suite per Linux.

L'agente di isolamento di Azure migliorato è disponibile sia per SUSE che per Red Hat e offre un failover del servizio molto più veloce rispetto alla versione precedente dell'agente.

Un'altra opzione di isolamento consiste nell'usare dischi condivisi di Azure per il dispositivo di isolamento. In SLES 15 SP1 o SLES per SAP 15 SP1 e versioni successive è possibile configurare un cluster Pacemaker usando dischi condivisi di Azure. Questa opzione è semplice e non richiede una porta di rete aperta come l'agente di isolamento di Azure.

Una configurazione Pacemaker supportata e più semplice di recente in SLES 15 e versioni successive è SAP NetWeaver con alta disponibilità con mount semplice e NFS su VM SLES per applicazioni SAP. In questa configurazione, le condivisioni file SAP vengono estratte dalla gestione del cluster, semplificando il funzionamento. Usare questa configurazione a disponibilità elevata per tutte le nuove distribuzioni.

Per gestire ulteriormente i costi di un ampio panorama applicativo SAP, il cluster Linux supporta l'installazione multi-SID ASCS in Azure. La condivisione di un cluster di disponibilità tra più sistemi SAP semplifica il panorama applicativo SAP e riduce i costi operativi.

In Load Balancer Standard è possibile abilitare la porta a disponibilità elevata ed evitare la necessità di configurare le regole di bilanciamento del carico per molte porte SAP. In generale, se si abilita la funzionalità direct server return (DSR) quando si configura un servizio di bilanciamento del carico, le risposte del server alle richieste dei client possono ignorare il servizio di bilanciamento del carico. Questa funzionalità è nota anche come IP fluttuante. Il servizio di bilanciamento del carico può essere locale o in Azure. Questa connessione diretta impedisce al bilanciamento del carico di diventare il collo di bottiglia nel percorso della trasmissione dei dati. Per i cluster di database ASCS e HANA, è consigliabile abilitare DSR. Se le macchine virtuali nel pool back-end richiedono la connettività in uscita pubblica, è necessaria un'ulteriore configurazione .

Per il traffico dai client dell'interfaccia grafica SAP che si connettono a un server SAP tramite il protocollo DIAG o RFC, il server di messaggi dei Servizi Centrali bilancia il carico usando i gruppi di login del server applicazioni SAP. Non è necessario alcun servizio di bilanciamento del carico aggiuntivo.

I server di applicazione nel livello dei server di applicazione

È possibile ottenere l'alta disponibilità bilanciando il carico del traffico all'interno di un pool di server di applicazioni.

Livello database

L'architettura di questa guida illustra un sistema di database SAP HANA a disponibilità elevata costituito da due macchine virtuali di Azure. La funzionalità di replica del sistema native del livello database fornisce un failover manuale o automatico tra i nodi replicati.

• Per il failover manuale, implementare più istanze di HANA e usare HSR.

• Per il failover automatico, utilizzare sia l'estensione HSR che l'estensione Linux HA (HAE) per la vostra distribuzione Linux. Linux HAE fornisce servizi cluster per le risorse HANA, rileva gli eventi di errore e orchestra il failover dei servizi difettosi in un nodo integro.

Distribuire macchine virtuali tra zone di disponibilità

Le zone di disponibilità possono migliorare la disponibilità del servizio. Le zone fanno riferimento a posizioni separate fisicamente all'interno di un'area di Azure specifica. Migliorano la disponibilità del carico di lavoro e proteggono i servizi delle applicazioni e le macchine virtuali dalle interruzioni del data center. Le macchine virtuali in una singola zona vengono considerate come se si trovino in un singolo dominio di aggiornamento o di errore. Quando si seleziona la distribuzione a livello di zona, le macchine virtuali che si trovano nella stessa zona vengono distribuite ai domini di errore e di aggiornamento su base miglior sforzo.

Nelle aree di Azure che supportano questa funzionalità sono disponibili almeno tre zone. La distanza massima tra data center in queste zone non è garantita. Per distribuire un sistema SAP a più livelli tra zone, è necessario conoscere la latenza di rete all'interno di una zona e tra zone di destinazione e il modo in cui le applicazioni distribuite sono sensibili 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 o dei tipi di macchina virtuale nelle zone scelte

Esempio di distribuzione attiva/passiva

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 è costruito nella zona 2, ma è spento. Vengono attivati solo quando necessario.

I cluster a due nodi per Central Services e il database vengono estesi tra due zone. Se la zona 1 ha esito negativo, i Servizi centrali 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 collocati nella stessa zona, la latenza di rete è minimizzata.

Esempio di distribuzione attiva/attiva

In una distribuzione attiva/attiva, due set di server di applicazione vengono costruiti in due zone. In ogni zona, sono attivi due server di applicazioni per ciascun set. Di conseguenza, sono presenti server applicazioni attivi in entrambe le zone nelle normali operazioni.

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

Se la zona 1 passa offline, i servizi ascs e database eseguono il failover nella zona 2. I server applicazioni inattivi possono essere portati online per fornire capacità completa per l'elaborazione delle applicazioni.

Considerazioni sulla disaster recovery

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

Considerazioni sui costi

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

Per altre informazioni, vedere Ottimizzazione dei costi di Azure Well-Architected Framework.

Macchine virtuali

Questa architettura usa macchine virtuali che eseguono Linux per i livelli di gestione, applicazione SAP e database.

Esistono diverse opzioni di pagamento per le macchine virtuali:

• Per i carichi di lavoro che non hanno un tempo prevedibile 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 risparmiare fino a 72% rispetto alle opzioni 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 c'è capacità disponibile e le recupera quando necessita nuovamente della capacità. I costi delle 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.

Per una panoramica dei prezzi, vedere Prezzi delle macchine virtuali Linux.

Bilanciatore di carico

In questo scenario, i servizi di bilanciamento del carico di Azure vengono usati per distribuire il traffico alle macchine virtuali nella subnet del livello applicazione.

Viene addebitato solo il numero delle regole configurate di bilanciamento del carico e di uscita. Le regole di conversione degli indirizzi di rete 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 predeterminata. Per altre informazioni, vedere Prezzi di ExpressRoute.

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. L'esperienza di distribuzione guidata di Centro di Azure per soluzioni SAP crea i componenti di calcolo, archiviazione e rete necessari per eseguire il sistema SAP. È quindi possibile automatizzare l'installazione del software SAP in base alle procedure consigliate di Microsoft. È possibile sfruttare le funzionalità di gestione sia per i sistemi SAP nuovi che per i sistemi SAP esistenti.

salvataggio dei dati

È possibile eseguire il backup dei dati SAP HANA in molti modi. Dopo la migrazione ad Azure, continuare a usare tutte le soluzioni di backup esistenti disponibili. Azure offre due approcci nativi per il backup. È possibile eseguire il backup di SAP HANA nelle macchine virtuali o usare Backup di Azure a livello di file. Backup di Azure è certificato Backint da SAP. Per altre informazioni, vedere Backup di Azure domande frequenti e Matrice di supporto per il backup dei database SAP HANA nelle macchine virtuali di Azure.

Gestione delle identità

Usare un sistema di gestione delle identità centralizzato per controllare l'accesso alle risorse a tutti i livelli.

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

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

• Supportare l'accesso all'interno delle app stesse tramite i servizi forniti da SAP o 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. Azure Monitor è una soluzione completa per la raccolta, l'analisi e l'intervento sui dati di telemetria dai tuoi 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 sulla sicurezza

SAP dispone di un proprio motore di gestione utenti per controllare l'accesso e l'autorizzazione in base al ruolo all'interno dell'applicazione e dei database SAP. Per altre informazioni, vedere Panoramica della sicurezza di SAP HANA.

Per migliorare la 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 e i pool di server front-end Fiori. Per ridurre al minimo i costi di trasferimento dei dati, distribuire server front-end attivi che ospitano applicazioni Fiori all'interno della stessa rete virtuale dei sistemi S/4. In alternativa, è possibile configurare questi server front-end nella rete perimetrale, che sfrutta il peering di rete virtuale per stabilire la connettività con i sistemi S/4.

Per la sicurezza dell'infrastruttura, vengono crittografati sia i dati in transito sia quelli inattivi. Per informazioni sulla sicurezza di rete applicabile a S/4HANA, vedere Sicurezza per il tuo panorama SAP.

Per crittografare i dischi delle macchine virtuali Linux, sono disponibili diverse opzioni. Per la crittografia dei dati inattivi SAP HANA, è consigliabile usare la tecnologia di crittografia nativa di SAP HANA. Per il supporto della crittografia dischi di Azure in distribuzioni, versioni e immagini linux specifiche, vedere Crittografia dischi di Azure per le macchine virtuali Linux.

Comunità

Le community possono rispondere alle domande ed essere utili per configurare correttamente la distribuzione. Considerare le seguenti risorse:

• Eseguire applicazioni SAP nel blog della piattaforma Microsoft
• Supporto della community di Azure
• Community SAP
• SAP in Stack Overflow

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autore principale:

• Ben Trinh | Architetto principale

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

Passaggi successivi

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

• Distribuire SAP S/4HANA o BW/4HANA in Azure
• Usare Azure per ospitare ed eseguire scenari di carico di lavoro SAP
• Pianificazione e implementazione di macchine virtuali per SAP NetWeaver

Risorsa collegata

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