SAP S/4HANA in Linux in 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 sistema di produzione comune. Questa architettura viene distribuita con dimensioni di macchina virtuale (VM) che è possibile modificare per soddisfare le esigenze dell'organizzazione. Per soddisfare le esigenze aziendali, è possibile ridurre questa configurazione 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.

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

Rete virtuale di Azure. Il servizio Rete virtuale connette in modo sicuro le risorse di Azure tra loro. 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 reti virtuali. Questa architettura usa più reti virtuali con peering. Questa topologia offre 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 implementata all'interno di una singola area. Le subnet separate vengono usate per ogni applicazione livello (SAP NetWeaver), database e per i servizi condivisi, ad esempio la jump box e Windows Server Active Directory.

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

• 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 la disponibilità elevata di Central Services in Azure in esecuzione in macchine virtuali Linux, è necessario un servizio di condivisione file di rete a disponibilità elevata, ad esempio condivisioni file NFS in File di Azure, Azure NetApp Files, server NFS (Clustered Network File System) 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 per ottenere disponibilità elevata.

• SAP HANA. Il livello di database usa due o più macchine virtuali Linux in un cluster per ottenere una 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 semplificare il failover automatico. È necessario usare un meccanismo di isolamento basato sull'archiviazione o basato sul cloud per assicurarsi che il sistema non riuscito sia isolato o arrestato per evitare la condizione split-brain del cluster. 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 tramite il client SSH o RDP nativo già installato nel computer locale. Se per l'amministrazione vengono usati solo RDP e SSH, Azure Bastion è una soluzione ideale. 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.

DNS privato servizio. Azure DNS privato fornisce un servizio DNS affidabile e sicuro per la 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 la disponibilità elevata, è consigliabile usare Azure Load Balancer Standard. Si noti che Load Balancer Standard fornisce 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 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.
• Servizi di rete necessari, 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 questi componenti:

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

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

Load Balancer Standard supporta anche cluster SAP con più sid (multi-SID). In altre parole, più sistemi SAP in SLES o RHEL possono 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. 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 e alla porta di origine 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). S/4HANA offre servizi di applicazioni Web tramite Fiori. È possibile bilanciare il carico di questo front-end Fiori, costituito da app Web, usando gateway applicazione.

Gateway. 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 Internet pubblico, ma è anche possibile usare una connessione da sito a sito . Per ridurre la latenza, Copertura globale di ExpressRoute ed ExpressRoute FastPath sono opzioni di connettività descritte più avanti in questo articolo.

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 usa gateway di rete virtuale con ridondanza della 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à favorisce la condivisione della posizione, che inserisce le macchine virtuali nello stesso data center per ridurre al minimo la latenza dell'applicazione.

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

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.

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 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 informazioni dettagliate sull'esecuzione di SAP NetWeaver nelle macchine virtuali, vedere Guida alla pianificazione e all'implementazione di Azure Macchine virtuali. La guida si applica anche alle distribuzioni SAP S/4HANA.

Per informazioni dettagliate sul supporto SAP per i tipi di macchine virtuali di Azure e per le metriche di velocità effettiva (SAPS), vedere SAP Note 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 SAP Certified and Supported SAP HANA Hardware Directory (Directory hardware SAP HANA certificata e supportata).

Dispatcher Web SAP

Il componente Web Dispatcher viene usato per il bilanciamento del carico del traffico SAP tra i server applicazioni SAP. Per ottenere una disponibilità elevata 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 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.

Server front-end Fiori (FES)

Questa architettura soddisfa molti requisiti e presuppone che venga usato il modello Fiori FES incorporato. Tutti i componenti tecnologici sono installati nel sistema S/4 stesso, vale a dire che ogni sistema S/4 ha il proprio launchpad Fiori. La configurazione a disponibilità elevata per questo modello di distribuzione è quella del sistema S/4. Non sono necessari clustering aggiuntivi o macchine virtuali. Per questo motivo, il diagramma dell'architettura non mostra il componente FES.

Per una descrizione delle opzioni di distribuzione principali, incorporate o hub, a seconda degli scenari, 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 dell'hub adatta solo a pochi casi d'uso ristretti.

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 multi-host: usare un livello di database del server di standby, un livello ASCS cluster con NFS a disponibilità elevata per l'archiviazione condivisa e almeno due server applicazioni. 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. Usare Web application firewall di Azure in gateway applicazione come componente critico per deviare le minacce. Usare Microsoft Entra ID con SAML per l'autenticazione utente e SSO per SAP Fiori.

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

Pool di server applicazioni

Per gestire i gruppi di accesso per i server applicazioni ABAP, è comune usare la transazione SMLG per bilanciare il carico degli utenti di accesso, per usare SM61 per i gruppi di server batch, per usare RZ12 per i gruppi RFC (Remote Function Call) e così via. Queste transazioni usano la funzionalità di bilanciamento del carico presente nel server messaggi di Central Services per distribuire sessioni o carichi di lavoro in ingresso tra il pool di server applicazioni SAP che gestiscono il traffico SAP GUIs e RFC.

Cluster SAP Central Services

È 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. Tuttavia, la macchina virtuale diventa un potenziale singolo punto di errore (SPOF) per l'ambiente SAP. Per una distribuzione di Central Services a disponibilità elevata, usare NFS su File di Azure o il servizio Azure NetApp Files e un cluster di Servizi centrali.

Un'altra opzione consiste nell'usare dischi condivisi di Azure per ottenere una disponibilità elevata. In SLES 15 SP1 e versioni successive o SLES for SAP Applications è possibile configurare un cluster Pacemaker usando dischi condivisi di Azure per Linux.

In alternativa, è possibile usare una condivisione file NFS per l'archiviazione condivisa del cluster Linux.

In una distribuzione di Azure, i server applicazioni si connettono a Central Services con disponibilità elevata tramite i nomi host virtuali di Central Services 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, quindi sia gli INDIRIZZI VIP virtuali di Central Services che gli INDIRIZZI IP virtuali (ERS) possono essere configurati in un unico servizio di bilanciamento del carico.

Il supporto del cluster Linux per l'installazione multi-SID ASCS in Azure è ora disponibile a livello generale. La condivisione di un cluster di disponibilità tra più sistemi SAP semplifica il panorama sap.

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 gli spoke 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 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. Di conseguenza, l'uso di più schede di interfaccia di rete non è necessario per considerazioni sulle prestazioni. Tuttavia, se l'organizzazione deve separare il traffico, è possibile distribuire più schede di interfaccia di rete per macchina virtuale, connettere ogni scheda di interfaccia di rete a una subnet diversa e 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, come descritto nella nota SAP 962955. Per accedere alle note SAP, è necessario un account SAP Service Marketplace.

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. 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ù circuiti ExpressRoute, Copertura globale di ExpressRoute consente di ridurre gli hop di rete e una latenza inferiore. Questa tecnologia è un peering di route BGP (Border Gateway Protocol) configurato tra due o più circuiti ExpressRoute per collegare due domini di routing ExpressRoute. Copertura globale riduce la latenza quando il traffico di rete attraversa più circuiti ExpressRoute. Attualmente è disponibile solo per il peering privato nei circuiti ExpressRoute.

Attualmente 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 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 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.

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 offre servizi a livello di applicazione (definiti livello 7 nel modello di rete ISO) in grado di terminazione SSL e altre funzioni di offload.

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. 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 Azure Load Balancer Standard per tutti gli scenari SAP. È importante notare che 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 dai client DELL'interfaccia utente grafica 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. Non è necessario alcun servizio di bilanciamento del carico aggiuntivo.

Storage

Alcuni clienti usano l'archiviazione standard per i server applicazioni. Poiché i dischi gestiti standard non sono supportati, come indicato nella nota SAP 1928533, è consigliabile usare dischi gestiti di Azure Premium o Azure NetApp Files 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.

Poiché i server applicazioni non ospitano dati aziendali, è anche possibile usare i dischi P4 e P6 Premium più piccoli per gestire i costi. Per comprendere in che modo il tipo di archiviazione influisce sul contratto di servizio di disponibilità della macchina virtuale, vedere Contratto di servizio per Macchine virtuali. 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.

È possibile usare dischi condivisi di Azure con Windows Server, SLES 15 SP 1 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 dispositivo a blocchi STONITH (SBD). Offre un voto quorum in una situazione di partizionamento di rete del cluster. 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 offre la disponibilità per le condivisioni NFS che possono essere usate per /hana/sharedi volumi , /hana/datae /hana/log . Per la garanzia di disponibilità, vedere Contratto di servizio per Azure NetApp Files. 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 ad accesso sporadico e archivio di Azure. Questi livelli di archiviazione sono modi convenienti per archiviare dati di lunga durata a cui si accede raramente. È anche possibile prendere in considerazione l'uso del livello standard di Azure NetApp Files 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 ad accesso sporadico o archivio di Azure.

Il livello di prestazioni Ultra Disk Storage e Azure NetApp Files riducono notevolmente la latenza del disco e traggono vantaggio dalle applicazioni critiche per le prestazioni e i server di database SAP.

Ssd Premium di Azure v2 è progettato per carichi di lavoro critici per le prestazioni, ad esempio SAP. Per informazioni sui vantaggi di questa soluzione di archiviazione e sulle limitazioni correnti, 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. In questo modo è possibile 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'hyperthreading, le istanze di macchine virtuali con quattro o più vCPU supportano la rete accelerata.

Per informazioni dettagliate sui requisiti di prestazioni di SAP HANA, vedere la nota SAP 1943937 - Strumento di controllo della configurazione hardware. Per accedere alle note SAP, è necessario un account SAP Service Marketplace.

Per ottenere un numero elevato di operazioni di I/O al secondo e velocità effettiva della larghezza di banda del disco, le procedure comuni nell'ottimizzazione delle prestazioni del volume di archiviazione si applicano al layout di archiviazione. Ad esempio, se si combinano più dischi per creare un volume disco con striping, è possibile migliorare le prestazioni di I/O. Abilitando la cache di lettura nel contenuto di archiviazione che cambia raramente, è possibile migliorare la velocità di recupero dei dati. Per consigli sulle configurazioni di archiviazione per diverse dimensioni delle macchine virtuali quando si esegue SAP HANA, vedere Configurazioni di archiviazione delle macchine virtuali di Azure SAP HANA.

Ssd Premium di Azure v2 è progettato per carichi di lavoro critici per le prestazioni, ad esempio SAP. Per informazioni sui vantaggi e sulle limitazioni e sugli scenari di utilizzo 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 le metriche come IOPS e MB/s senza riavviare la macchina virtuale. Quando è disponibile l'archiviazione su disco Ultra, è consigliabile l'archiviazione su disco Ultra anziché l'acceleratore di scrittura.

Alcune applicazioni SAP richiedono una comunicazione frequente con il database. La latenza di rete tra i livelli dell'applicazione e del database, a causa della distanza, 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 co-posizione 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. L'appliance virtuale di rete richiede una quantità significativa 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, come descritto più avanti in questo articolo. È consigliabile creare 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 che è possibile usare, vedere Test della latenza della zona di disponibilità.

Azure NetApp Files offre funzionalità di prestazioni uniche che rendono possibile l'ottimizzazione in tempo reale che soddisfi le esigenze degli ambienti SAP più esigenti. Per considerazioni sulle prestazioni da tenere presenti 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 macchine virtuali per l'aumento e la scalabilità orizzontale. Per un elenco inclusivo, vedere "Applicazioni SAP in Azure: Prodotti supportati e tipi di macchine virtuali di Azure" nella nota SAP 1928533. Per accedere alle note SAP, è necessario un account SAP Service Marketplace. Più tipi di vm vengono continuamente certificati, quindi è possibile aumentare o ridurre le prestazioni nella stessa distribuzione cloud.

A livello di database, questa architettura esegue applicazioni SAP HANA S/4 in macchine virtuali di Azure con scalabilità fino a 24 terabyte (TB) in un'istanza. Se il carico di lavoro supera le dimensioni massime della macchina virtuale, è possibile usare una configurazione multinodo per un massimo di 96 TB (4 x 24) per le applicazioni OLTP (Online Transaction Processing). Per altre informazioni, vedere Certified and Supported SAP HANA Hardware Directory (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 diversi tipi di archiviazione, vedere Contratto di servizio per 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à.

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.

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 (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.

Dispatcher Web nel livello server applicazioni

È possibile ottenere la disponibilità elevata usando istanze ridondanti di Web Dispatcher. Per altre informazioni, vedere SAP Web Dispatcher nella documentazione di SAP. 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 co-individuare Web Dispatcher con le macchine virtuali ASCS. In questo modo, è possibile risparmiare sulla manutenzione indipendente del sistema operativo e ottenere la disponibilità elevata contemporaneamente.

Central Services nel livello server applicazioni

Per la disponibilità elevata di Central Services in macchine virtuali Linux di Azure, usare l'estensione di disponibilità elevata appropriata per la distribuzione Linux selezionata. È consuetudine inserire i file system condivisi nell'archiviazione NFS a disponibilità elevata usando SUSE DRBD o Red Hat GlusterFS. Per fornire un NFS a disponibilità elevata ed eliminare la necessità di un cluster NFS, è invece possibile usare altre soluzioni convenienti o affidabili come NFS su File di Azure o Azure NetApp Files. Come nota collaterale, 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 funziona bene per le condivisioni file a disponibilità elevata, ad esempio quelle di /sapmnt, /saptrans nelle installazioni SAP.

Azure NetApp Files supporta la disponibilità elevata di ASCS in SLES. Per informazioni dettagliate su ASCS in RHEL a disponibilità elevata, 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 notevolmente più veloce rispetto alla versione precedente dell'agente.

Un'altra opzione consiste nell'usare dischi condivisi di Azure per ottenere una disponibilità elevata. In SLES 15 SP 1 e versioni successive o SLES per SAP è possibile configurare un cluster Pacemaker usando dischi condivisi di Azure per ottenere la disponibilità elevata.

In Azure 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 mobile. Il servizio di bilanciamento del carico può essere locale o in Azure. Questa connessione diretta impedisce al servizio di bilanciamento del carico di diventare il collo di bottiglia nel percorso della trasmissione dei dati. Per i cluster ASCS e HANA DB, è consigliabile abilitare DSR. Se le macchine virtuali nel pool back-end richiedono la connettività in uscita pubblica, sono necessarie altre configurazioni .

Per il traffico dai client DELL'interfaccia utente grafica SAP che si connettono a un server SAP tramite il protocollo DIAG o RFC, il server messaggi di Central Services bilancia il carico usando i gruppi di accesso del server applicazioni SAP. Non è necessario alcun servizio di bilanciamento del carico aggiuntivo.

Server applicazioni nel livello server applicazioni

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

Livello ASCS

Come per il livello server applicazioni, la soluzione di disponibilità elevata HANA distribuita comunemente per Linux è Pacemaker.

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 nativa del livello di database offre failover manuale o automatico tra i nodi replicati:

• Per il failover manuale, distribuire più istanze di HANA e usare HSR.
• Per il failover automatico, usare sia HSR che Linux high availability extension (HAE) per la distribuzione Linux. Linux HAE fornisce i servizi cluster alle risorse HANA rilevando gli eventi di errore e orchestrando il failover dei servizi in errore nel 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 fossero in un singolo dominio di aggiornamento o di errore. Quando si seleziona la distribuzione a livello di zona, le macchine virtuali nella stessa zona vengono distribuite ai domini di errore e di aggiornamento su base ottimale.

Nelle aree di Azure che supportano questa funzionalità sono disponibili almeno tre zone. Tuttavia, la distanza massima tra i data center in queste zone non è garantita. Per distribuire un sistema SAP multilivello 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 (tipi di vm) 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 è integrato nella zona 2, ma viene arrestato. Vengono attivati solo quando sono necessari.

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 che si trova 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. In ogni zona, due server applicazioni in ogni set sono inattivi o arrestati. 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 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 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.

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 in generale:

• Per i carichi di lavoro senza tempi prevedibili di completamento o consumo delle 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 su questa offerta, vedere Istanze di macchine virtuali riservate di Azure.

Per una panoramica dei prezzi, vedere Prezzi di Linux Macchine virtuali.

Load Balancer

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.

Vengono addebitati solo il numero di regole di bilanciamento del carico e in uscita configurate. 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.

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 di Microsoft. È possibile sfruttare le funzionalità di gestione per sistemi SAP nuovi e esistenti. Per altre informazioni, vedere Centro di Azure per soluzioni SAP.

Backup

È possibile eseguire il backup dei dati SAP HANA in molti modi. Dopo la migrazione ad Azure, continuare a usare 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 è BackInt certificato 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 LDAP (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, 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 il proprio motore di gestione degli utenti (UME) per controllare l'accesso e l'autorizzazione basati sui ruoli all'interno dell'applicazione e dei database SAP. Per informazioni dettagliate, vedere Sicurezza di SAP HANA: panoramica.

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. Il costo del trasferimento dei dati è un motivo per inserire server front-end attivi che eseguono app Fiori nella stessa rete virtuale dei sistemi S/4. L'alternativa consiste nel posizionarli nella rete perimetrale e connetterli a S/4 tramite un peering di rete virtuale.

Per la sicurezza dell'infrastruttura, vengono crittografati sia i dati in transito sia quelli inattivi. La sezione "Considerazioni sulla sicurezza" di SAP NetWeaver in Azure Macchine virtuali-Planning and Implementation Guide contiene informazioni sulla sicurezza di rete applicabile a S/4HANA. Questa guida specifica anche le porte di rete da aprire nei firewall per consentire la comunicazione dell'applicazione.

Per crittografare i dischi delle macchine virtuali Linux, sono disponibili varie opzioni, come descritto in Panoramica della crittografia del disco. Per la crittografia dei dati inattivi sap HANA, è consigliabile usare la tecnologia di crittografia nativa 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.

Per la crittografia dei dati inattivi sap HANA, è consigliabile usare la tecnologia di crittografia nativa SAP HANA.

Community

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

• Blog Running SAP Applications on the Microsoft Platform (Esecuzione di applicazioni SAP nella piattaforma Microsoft)
• Supporto della community di Azure
• Community SAP
• SAP in Stack Overflow

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:

• Distribuire SAP S/4HANA o BW/4HANA in Azure
• 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